JPEG and PNG uploads are stored byte for byte. Other formats are re-encoded once at high quality — PNG when there is transparency, JPEG at quality 92 without chroma subsampling otherwise.

Why not keep the HEIC as well?

Because nothing downstream reads it reliably: most models reject it, and browsers disagree on it. The converted file is the one every model, browser and download can use.

What is still refused?

ICO, PSD and JPEG XL. Save them as JPG or PNG first.

Why every image you upload to LUVI becomes JPEG or PNG

iPhone HEIC photos used to fail in Chrome, WebP confused half the models, and one library's browser decoder took 27 seconds on a 12-megapixel shot. So we moved the conversion to the server and made one rule: every image is stored as JPEG or PNG, colour profile and orientation intact.

Image uploads look like the boring part of a generation platform. They were our most persistent source of support mail. This is what was going wrong, what we tried, and the rule that fixed it.

What was going wrong?

HEIC. Every iPhone shoots it by default. Safari can decode it; Chrome and Firefox cannot, so a Chrome user uploading a phone photo either got an error or a file no model would accept.

WebP and AVIF. Browsers love them; model providers do not. Several rows refused them outright, others accepted them and silently failed later.

Orientation and colour. A photo taken sideways carries a rotation tag that some decoders honour and some ignore; an iPhone photo carries a Display P3 colour profile that, dropped on conversion, makes the picture look flat.

Why not convert in the browser?

The obvious move is to convert in the browser before upload. We shipped a WebAssembly HEIC decoder and it died the same day: the library compiles its worker with new Function, which our Content Security Policy — the one that keeps the app safe from injected scripts — does not allow. Every Chrome HEIC upload threw an EvalError.

The library's CSP-safe build ran, but a 12-megapixel photo took 27 seconds to decode on a laptop. The same file takes 1.4 seconds on the server. And the HEIC was smaller than the JPEG it produced anyway, so converting on the device saved no bandwidth. We took the browser decoder out.

What is the rule now?

Every image is stored as JPEG or PNG. The format is read from the bytes, never from the file name or the content type — a JPEG named .png is stored as a JPEG. JPEG and PNG uploads are kept byte for byte. Everything else is converted on the server:

PNG if any pixel is transparent, so nothing gets flattened onto a background.
JPEG at quality 92 with full chroma otherwise.
The EXIF rotation is applied, so the stored image is upright.
The embedded colour profile is carried over; an iPhone's Display P3 image comes out looking like it did on the phone.
An animated GIF or WebP keeps its first frame; an SVG is rasterised at 2048 px on its long side.

The decoding stack is specific: one library for WebP, GIF, AVIF, TIFF and SVG; a dedicated HEIC decoder (the general-purpose one only handles the AV1 variant); a small BMP reader, because the image library has none. ICO, PSD and JPEG XL cannot be converted and are refused with a clear message.

Where does the conversion run?

Every entry point goes through the same function: the upload dialog, upload-by-URL, the direct-to-storage path large files use, and the connector's upload ticket for Claude. When a file is already in storage, it is read back, converted, written under its new name, and only then is the original removed. The upload response tells you the stored file name and what it was converted from.

What changed for you?

Phone photos upload in every browser. Every model receives a format it accepts. Downloads are files any application opens. And the conversion takes about a second, on our side, once.

The limits, for reference: images up to 50 MB; video, audio, 3D and PDF up to 1 GB. The full list of accepted formats is in the help center: what file formats and sizes can I upload? and why did my HEIC or WebP turn into a JPEG?