JPEG XL Sits at 15%. AVIF Is at 95%. That Is the Whole Decision

The JPEG XL argument is loud and mostly beside the point. It compresses better than AVIF at high quality, it decodes faster, it does lossless recompression of existing JPEGs. All true, and none of it matters until browsers ship it.

The numbers, from caniuse: WebP 96.18%, AVIF 94.67%, JPEG XL 15.02%. That last figure is Safari only, and only partially.

Key takeaways#

• AVIF is the default now at 94.67%, supported since Chrome 85, Firefox 93 and Safari 16.4.
• WebP is the fallback at 96.18%, and the marginally wider reach is not a reason to lead with it.
• JPEG XL is not deployable. Partial support in Safari 17+, and nothing else ships it on.
• Chrome has it flag-disabled again in 145–154, so "Chrome removed it" is out of date without being wrong.
• One <picture> element serves all three tiers and needs no JavaScript.

Why AVIF rather than WebP#

WebP has the wider number, so the instinct is to lead with it. The instinct is wrong, because you are not choosing one format.

AVIF is derived from AV1 and typically produces noticeably smaller files than WebP at the same perceived quality, with the gap widest on photographic content. WebP's advantage is a slightly longer support tail, and that tail is served by listing it second rather than first.

The one place WebP still wins outright is encoding cost. AVIF encoding is slow, sometimes dramatically so at high effort settings, which matters if you are transcoding on upload rather than at build time. If a user is waiting on the encoder, turn the effort down or generate AVIF asynchronously and serve WebP until it is ready.

Why JPEG XL keeps coming up and still cannot be used#

The technical case is genuinely strong, which is why the discussion will not die. The deployment case is not close.

Safari added partial support in 17.0. No other engine ships it enabled. Chrome carried it behind a flag from 91 to 109, removed it, and now shows as flag-disabled again in 145 through 154. Firefox has had it behind a flag since 90.

"Behind a flag" is not support. A feature a user must enable manually reaches approximately nobody, and the 15.02% figure counts Safari's partial implementation generously.

The practical consequence: you cannot serve JPEG XL as a primary format, and adding it as a fourth <source> buys a marginal saving for the Safari share while costing another encode of every image in your pipeline. Revisit when a second engine ships it on by default.

The four lines that handle all of it#

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

The browser takes the first type it understands, so the order is the priority order. The <img> is both the fallback and the element that carries alt, sizing and loading attributes.

Two details that are easy to omit and expensive to omit. width and height must be on the <img> so the browser can reserve space and avoid layout shift, and they are the intrinsic pixel dimensions rather than the displayed size. And the alt belongs on the <img>, not on a <source>, because the sources are not elements a screen reader ever sees.

If your framework has an image component, it is almost certainly emitting this for you and negotiating on Accept instead. Content negotiation reaches the same outcome with one URL, at the cost of needing a server that can vary the response.

Where data URLs fit#

Inlining an image as a Base64 data URL removes a request, and that is the entire benefit. The costs are consistent: about a third more bytes than the binary, no separate caching from the document, and no format negotiation at all, since a data URL commits you to one encoding for every visitor.

That last point matters here. An inlined image cannot participate in the <picture> fallback chain, so you are shipping AVIF to browsers that cannot read it or JPEG to browsers that deserved better.

The threshold worth applying is a couple of kilobytes. Below that, a tiny icon on the critical path is defensible. Above it, the size penalty and lost caching outweigh the saved connection, especially over HTTP/2 where the request was cheap anyway. The image to Base64 tool reports the encoded size so you can check the number before committing, and Base64 to image goes the other way when you need to see what a data URL in a stylesheet actually contains.

A short decision list#

1. Photographic content: AVIF first, WebP second, JPEG last.
2. Flat graphics and screenshots with text: AVIF or WebP lossless, PNG last.
3. Anything under about 2 kB and on the critical path: consider a data URL, then check the encoded size.
4. Animation: AVIF or WebP, never GIF, which is neither small nor good.
5. JPEG XL: not yet, and the blocker is deployment rather than merit.

The short version#

Compression benchmarks decide which format is better and browser support decides which format you can use, and right now those give different answers. AVIF at 94.67% is the working default, WebP at 96.18% is the fallback that costs nothing to include, and JPEG XL at 15.02% is a format to watch rather than ship. A <picture> element with two sources and an <img> handles the whole range.

Sources: Can I use: AVIF, Can I use: WebP, Can I use: JPEG XL