AVIF vs JPEG XL: The Format War

Use AVIF, because it ships in every major browser while JPEG XL does not. On most technical measures JPEG XL is the stronger format, offering lossless JPEG transcoding, progressive decoding and excellent quality per byte. It is also, for practical purposes, not deployable on the open web.

Chrome removed JPEG XL support in 2023, citing insufficient ecosystem interest, and without Chrome a web image format does not happen. AV1 Image File Format (AVIF) had the advantage of riding on AV1, a video codec browser vendors were already investing in. The better technology lost to the one with the stronger distribution story, which is not a new pattern.

How the 2 formats compare

JPEG XL wins on encoding speed, progressive loading and lossless JPEG conversion, while AVIF wins on the only measure that decides deployment, which is browser support.

The lossless JPEG transcoding row is the capability the web lost. JPEG XL can repackage an existing JPEG about 20 percent smaller and convert it back to the identical original file, which would have allowed archives to shrink with no risk at all.

Why Chrome removed JPEG XL

Chrome cited insufficient interest from the ecosystem, limited benefit over existing formats, and the maintenance cost of another decoder. The decision was announced in 2022 and took effect in 2023.

The reasoning was contested at the time and remains so. Supporters pointed to measurable compression advantages and to backing from several large image publishers. The counterargument was that AVIF already delivered most of the benefit using a decoder browsers had shipped for video. Whichever view is correct, a format without Chrome cannot be served to the majority of web traffic.

Where JPEG XL is still used

JPEG XL survives in professional photography, archival storage and Apple software, where a single vendor controls the pipeline. Safari added support in 2023, which keeps the format alive on Apple platforms.

• Photo archives use the lossless JPEG transcoding to reduce storage with no risk of loss.
• Professional camera workflows benefit from the high bit depth and wide colour support.
• Apple platforms can decode it, which makes it viable inside closed ecosystems.
• Medical and scientific imaging values the lossless mode and the progressive decoding.
• Not the open web, where a format has to work in every browser to be usable.

When to use AVIF on a website

Use AVIF on your largest photographs, where it saves 20 to 30 percent against WebP. The advantage grows with image size and disappears on small graphics.

Hero images, full width banners and photography galleries are the clear cases. Below roughly 10 KB an AVIF file is frequently larger than the WebP equivalent, because the container overhead outweighs the compression gain. Splitting a library by size, with AVIF on the heavy images and WebP on everything else, captures most of the benefit without the encoding cost.

The cost of AVIF encoding

AVIF encodes several times slower than WebP, which matters on large batches rather than on single images. A photograph that converts to WebP in under a second may take several seconds as AVIF.

On a batch of 500 images the difference is measured in minutes. That cost is paid once per image and never again, since decoding is fast in every supporting browser. Plan a large conversion when the machine is otherwise free, and keep the browser tab in the foreground, because browsers throttle background tabs and slow the work considerably.

How to serve AVIF safely

To use AVIF without breaking older browsers, follow these 5 steps.

1. Identify the largest images on each page, which are usually hero banners and lead photographs.
2. Reduce each image to the width it occupies on the page, doubled for high density screens.
3. Convert to AVIF at quality 60 to 70, since AVIF holds detail at lower numbers than JPEG does.
4. Convert the same source to WebP as a second option and keep the original JPEG as the final fallback.
5. Serve all 3 through a picture element with AVIF first, WebP second and JPEG in the img tag.

The browser takes the first format it understands, so nothing breaks anywhere. Writing the markup usually takes longer than converting the files.

AVIF quality settings behave differently

AVIF quality 60 looks comparable to JPEG quality 85, so the familiar numbers do not transfer. Using JPEG habits with AVIF produces files far larger than necessary.

Start at 60 for photographs and adjust from there. Watch for a specific failure, since AVIF at aggressive settings tends to smooth fine texture rather than produce blocks, which can make grass, hair and fabric look painted. That artefact is less objectionable than JPEG blockiness and is easy to miss until someone points it out.

How a format wins or loses

Distribution decides image formats, not technical merit, and browser vendors control distribution. The same pattern produced the outcome for WebP, which succeeded because Chrome shipped it, and for JPEG 2000, which failed despite being technically capable.

AVIF benefited from a decision made about video rather than about images. Browser vendors had already invested in AV1 to reduce streaming costs, so an image format built on the same decoder cost them very little to add. JPEG XL required a new decoder, new maintenance and a new security surface, with a benefit browsers judged to be marginal against what they already shipped.

Does any of this affect ordinary users

No, most people never choose an image format directly, and the decision is made by the platform they publish through. The debate matters to site owners, photographers and developers who control their own delivery.

Anyone publishing through a marketplace, a social network or a hosted site builder is uploading JPG or PNG and letting the platform re-encode. The format argument reaches you only when you control the files a visitor downloads, which is why it dominates web performance discussions and is invisible everywhere else.

What this means for your library

Keep lossless masters, publish AVIF and WebP, and ignore the format debate. Delivery formats change every few years while a master file remains useful indefinitely.

Anyone who converted an entire library to a delivery format and deleted the originals has faced this problem before. Storage is inexpensive compared with re-photographing a catalogue, so the practical strategy is to store the best version you have and generate delivery copies as often as the web changes its mind.

Will JPEG XL come back

A return would require Chrome to reverse its decision, and no announcement suggests that is planned. Safari support and continued interest from photography software keep the format from disappearing entirely.

Formats have returned from worse positions before, so the question is open rather than closed. Building a website around that possibility would be unwise. Use AVIF and WebP for delivery today, keep masters in a lossless format, and adopting any future format becomes a batch conversion rather than a rebuild.

Converting a library to AVIF

Convert from the original master rather than from an existing JPEG, because a lossy source carries damage into the new file. The AVIF encoder spends bits describing JPEG artefacts it cannot distinguish from real detail.

Add up to 500 files together, or hand over a ZIP archive, and the entire set encodes in one run. Everything runs inside your browser on your own processor, so photography libraries, client work and unpublished campaign assets never reach a server. Encoding locally also means a large batch runs at the speed of your machine rather than the speed of an upload.