Choosing an image format: JPEG, WebP, AVIF and JPEG XL

There are four image formats worth considering for the web, and the honest answer to “which one” is that you will ship at least two. Support is uneven enough that a single format is either leaving compression on the table or leaving users behind.

What each one is actually for

JPEG is thirty years old and still the floor. Nothing decodes faster, nothing is more universally supported, and at high quality settings it is closer to the modern formats than people expect. Its weaknesses are real though: no alpha channel, visible blocking when pushed, and a hard limit on how far you can compress before it falls apart.

WebP is the safe upgrade. Roughly 25 to 30% smaller than JPEG at comparable quality, with alpha and lossless modes, and supported by every browser in use. It is not the best compressor here, but it is the one with the fewest asterisks.

AVIF is the strongest compressor at low bitrates, which is where most web images live. It holds shapes together at file sizes where JPEG has already collapsed into blocks. Two caveats: it encodes slowly, and its advantage narrows as quality rises, so for near-transparent quality the gap over a well-tuned JPEG is smaller than the headline numbers suggest.

JPEG XL is the best all-rounder on technical merit, with one genuinely unique feature: it can losslessly recompress an existing JPEG, shrinking it about 20% with the original file recoverable bit-for-bit. That is remarkable for archives. It is also the one you cannot ship on its own.

Support, as of mid-2026

Format	Support	Notes
JPEG	Universal	The fallback that always works
WebP	Universal in current browsers	Safe to ship as a sole modern format
AVIF	Roughly 93% globally, on by default in Chrome, Edge, Firefox and Safari	The practical modern default
JPEG XL	Safari 17+ only, around 15%	Chrome restored a Rust decoder in 145, still off by default

The JPEG XL situation is worth stating precisely because it has changed twice. Chrome shipped it, removed it in version 110, then landed a new Rust implementation in version 145 in early 2026, which remains disabled by default into the 151 line. Firefox has it behind a flag. Safari has shipped it natively since 17. So it works beautifully for a fraction of your audience and not at all for the rest.

Do not take that table’s word for it. Our browser capability report probes the browser you are reading this in right now, which is a better answer for your own testing than any coverage percentage.

Sources: JPEG XL browser support in 2026, JPEG XL explained.

What the numbers look like

We encode the same images to all four at identical byte budgets and score them, which is a more useful comparison than format-versus-format claims made at unspecified settings. On a detailed 768×512 photograph held to about 12 KB, JPEG XL scores SSIM 0.9452 where JPEG manages 0.8964: a visible gap at a size where JPEG is clearly struggling.

AVIF is ahead of JPEG XL at that budget, at 0.9630, which is the pattern to expect: AVIF wins where the bits are tightest, and JPEG XL’s advantages show up elsewhere. The same page also records where a format fails outright. On the densest of the three images, neither JPEG nor JPEG XL can hit the tightest budget at all, for unrelated reasons, and the page says so rather than quietly dropping them. The full set of measurements, with sliders, is on JPEG vs WebP vs AVIF vs JPEG XL.

The decision

For most sites, serve AVIF with a JPEG fallback and stop there:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <img src="photo.jpg" alt="…" width="1200" height="800">
</picture>

The browser takes the first source it understands. Add a WebP source between them if you support browsers old enough to lack AVIF but new enough to have WebP, which is a shrinking group. Add JPEG XL at the top if your audience skews Apple and your pipeline makes the extra encode cheap.

Two adjustments worth making:

• If you can only ship one modern format, ship WebP. It has no support caveats and still beats JPEG comfortably.
• If encode time matters (user uploads, on-the-fly resizing), AVIF’s cost is not theoretical. Measure it against your traffic before committing.

Two things people get wrong

Animated GIF is not an image decision. A GIF is a 256-colour, poorly compressed video. Any short loop is smaller and sharper as actual video, often by an order of magnitude. Convert it with the WebM builder rather than reaching for animated WebP or AVIF.

Format is the second lever, not the first. Serving a 4000-pixel-wide image into a 400-pixel slot wastes far more bytes than any format choice recovers. Get dimensions and srcset right first; then argue about codecs.

You can encode your own files to all four, in your browser and without uploading anything, in the image codec lab.