JPEG vs HEIC, WebP and AVIF for Client Galleries

Start with who has to open the file

A proofing gallery serves two different jobs, and they do not need the same format.

• Preview: what the browser draws while the client reviews. You control the pipeline, so you can pick whatever the browser supports and fall back when it does not.
• Download: a file that leaves your system and lands in an email attachment, a Word document, a print shop upload form or an agency's asset library. You do not control any of those.

Most format advice mixes these up. A format that is a great choice for a preview can be a terrible choice for a download, because the download has to survive software you will never see.

The four formats, side by side

Support below reflects what these formats have done in mainstream browsers and operating systems for several years. Check a current compatibility table before you build on an edge case, because support changes.

HEIC is the one that surprises people. It is the default capture format on iPhones, so a client may send you HEIC files without knowing it. It is a fine capture format and a poor exchange format. Chrome and Firefox do not display it, and many Windows installs need an extra codec to open it.

What the size savings actually look like

Newer formats are smaller at comparable visual quality, and that is real. The honest way to size it is arithmetic on your own assumptions, not a headline percentage.

Take a 2048 px long-edge preview of a 3:2 photo. That is 2048 × 1365 = 2,795,520 pixels. File size is pixels × bits per pixel ÷ 8, so the bits-per-pixel figure your encoder settles on is what matters.

These bits-per-pixel values are assumptions chosen to show the method, not measurements of any codec. Encode your own frames at the formats you are considering and read the byte counts off disk.

Now scale it. A 400-frame wedding gallery previewed at 699 KB per frame is 400 × 699 KB = 279,600 KB, roughly 280 MB, if a client scrolls every frame. At 349 KB it is roughly 140 MB. Half the bytes matters on a phone on mobile data. It matters much less on an office connection, which is why the gain is worth chasing for previews and not worth risking a broken download for.

Colour is where formats quietly fail

A smaller file is no use if the colour shifts. Whatever format you serve, the embedded colour profile has to travel with it, and the browser has to honour it. The usual failure is a wide-gamut export that gets stripped of its profile during resizing and then looks flat or oversaturated on the client's screen.

Test this the boring way: export a frame with a saturated colour you know well, open the preview and the download on a phone and a laptop, and compare to your calibrated screen. If you have not settled which profile to deliver, our guide to sRGB, Adobe RGB and Display P3 for client delivery covers the decision by destination. Convert to sRGB for anything where you cannot verify the viewer, and keep the profile embedded.

Bit depth is the other quiet limit. JPEG is 8 bits per channel. If you are delivering a graded file with smooth skies or gradients, 8-bit JPEG can show banding at heavy compression. That is a reason to raise JPEG quality on those frames, not a reason to send a format the client cannot open.

A pipeline that uses each format where it fits

In practice that means three steps. First, keep the master as it came out of your edit. Second, generate a preview size in a modern format with a JPEG fallback so an older browser still shows something. Third, generate the download as a JPEG in sRGB with the profile embedded. Anyone can build this with an image CDN or a resize function, and some review tools do it for you, including Appruva, which serves downsized previews to the reviewer while the original stays on file.

The same logic applies to RAW. Clients never see a RAW file, and shouldn't have to; a proxy preserves the decision without the format problem. We cover that in why clients get proxies instead of RAW files.

Pick the preview size before you pick the codec

Dimensions move file size more than format does. File size scales with pixel count, so halving the long edge cuts the pixels to a quarter. A 2048 px preview has 2,795,520 pixels; a 1024 px preview of the same 3:2 frame has 1024 × 683 = 699,392 pixels, about a quarter as many. Even at identical bits per pixel, that is a quarter of the bytes.

That is why a gallery should serve more than one size. A grid of thumbnails needs a few hundred pixels. A review view needs enough resolution to judge focus and skin texture, which usually means the full screen width of the client's display and no more. Only the zoomed-in 100% view, if you offer one, needs the large file.

• Thumbnails: small, aggressively compressed, loaded lazily as the client scrolls.
• Review size: sized to the screen, with quality high enough that retouching decisions are still visible.
• Zoom or original: fetched only when asked for.

A client choosing between two near-identical frames is judging expression and sharpness. If your compression smears fine detail, they will pick on the wrong evidence, or ask for a re-export. Raise quality until detail you care about, such as eyelashes, fabric weave and text on a product label, is intact at the review size, then stop.

PNG, TIFF and the formats to leave out

Two more formats come up in client conversations, and both usually belong outside the gallery.

PNG is lossless, which sounds like a virtue and costs a great deal on photographs. A 2,795,520-pixel frame stored at 24 bits per pixel before compression is 2,795,520 × 24 ÷ 8 = 8,386,560 bytes, about 8.4 MB, and PNG's lossless compression of photographic detail rarely shrinks that dramatically. Keep PNG for graphics, logos and images with transparency, not frames of people or places.

TIFF is a print and archive format. Browsers do not display it, clients cannot preview it from an email, and the files are large. If a printer wants one, send it to the printer directly and keep it out of the review link.

The same discipline applies to GIF and to very old formats a client may ask for. If someone needs a specific format for a specific destination, such as a publication's content system, deliver that file on request. Do not make it the default for everybody.

What to do when a client sends you HEIC

A client sends reference images, a moodboard or brand photos straight from an iPhone, and they arrive as HEIC. Three habits keep this from becoming a support thread.

1. Convert on receipt. Turn the file into JPEG or PNG before it goes into any shared system. Do it once, not every time someone fails to open it.
2. Keep the original. The HEIC may carry depth or Live Photo data you will not want to lose. Archive it and work from the conversion.
3. Tell the client once. A single line in your onboarding message ("if you send photos from an iPhone, JPEG or a link to the album is easiest") prevents most of it. On the iPhone, the setting is under Camera, Formats, where "Most Compatible" captures JPEG.