JPEG XL vs AVIF: Archibald's benchmarks pick a winner by use case

What happened

Jake Archibald — ex-Chrome DevRel, author of the service worker spec, and one of the few people whose image-format opinions move committees — published a long head-to-head of JPEG XL vs AVIF for web use-cases. It is not a vibes piece. He ran both codecs across photographic content, screenshots, illustrations, and lossless source material, and measured compressed size at matched visual quality using butteraugli and SSIMULACRA2 rather than eyeballing it.

The headline finding: there is no single winner, and anyone telling you otherwise is selling a codec. AVIF, built on the AV1 video codec's intra-frame coding, continues to produce the smallest files at the aggressive end of the quality curve — the kind of thumbnails and hero photos where you're already accepting visible artifacts to hit a byte budget. JPEG XL wins everywhere else that matters on the web: high-fidelity photos, screenshots with text and sharp edges, illustrations with large flat regions, and anything you need to serve losslessly.

The benchmarks also surface two JXL-exclusive capabilities Archibald argues the web has been quietly missing. Progressive decoding — the modern descendant of the 1990s interlaced JPEG — lets a partially-downloaded JXL render a usable preview from the first few kilobytes. And JXL can losslessly transcode existing JPEGs to ~20% smaller files, which means a CDN can shrink the entire backlog of the web's JPEGs without any quality loss and reverse the operation bit-for-bit.

Why it matters

The context behind the post is a four-year-old political fight dressed up as a technical one. Chrome shipped JPEG XL behind a flag, then yanked it in 2023 citing "not enough interest from the ecosystem" — the same ecosystem that was waiting for Chrome to ship it. Safari added JXL in 16.4 that same spring. Firefox has it behind `image.jxl.enabled`. The format is an ISO standard (ISO/IEC 18181), has a reference encoder (`libjxl`) that is actively maintained, and ships in iOS, macOS, and now most Linux image viewers.

Archibald's benchmarks matter because they close the loop on Google's stated reason for removal. The 2023 explanation leaned on "insufficient incremental benefits" over existing formats. The numbers in this post — specifically on screenshots, illustrations, and the lossless JPEG transcode path — are hard to square with that framing. On lossless, JXL beats PNG by 30-50% depending on content; on screenshots at high quality, it beats AVIF by double-digit percentages while decoding faster. Those are not rounding errors.

The community reaction on the HN thread (221 points) splits predictably. One camp reads the benchmarks as a vindication of the "Chrome should reinstate JXL" petition that gathered thousands of signatures from Adobe, Facebook, Intel, Krita, and the Serenity OS maintainers in 2023. Another camp — smaller but louder in Chromium circles — argues AVIF is good enough, the web doesn't need two next-gen formats, and shipping JXL would fragment the encoder-tuning work that CDN vendors have poured into AVIF pipelines.

Both sides are directionally correct and that is the actual story. AVIF is good enough for the 80% of web images that are compressed photos below the threshold where you'd notice JXL's edge. JXL is strictly better for the other 20% — and "the other 20%" includes most of the content that pays the web's bills: product shots, UI screenshots in docs, illustration-heavy marketing pages, and the eye-wateringly large originals that image CDNs transcode on the fly.

What this means for your stack

If you're running an image pipeline today — a Cloudflare Images or imgproxy or Thumbor in front of an S3 bucket — the Archibald data pushes toward a specific `` arrangement rather than a format bet:

```html ```

Safari users (roughly 20% of global traffic, higher on consumer-facing sites) get the JXL. Chrome and Firefox users get AVIF. Everyone else gets the JPEG fallback. The cost is one extra encode per asset, which is cheap given `libjxl`'s encode speed is competitive with `libaom-avif` at matched quality.

The second takeaway is for anyone operating a CDN or object store at scale: the lossless-JPEG-to-JXL transcode is the single highest-leverage image optimization still on the table, because it requires no re-encoding decisions, no quality tuning, and is fully reversible. If you have a petabyte of legacy JPEGs, you can shrink the pile by ~20% today, serve JXL to Safari, and reconstruct the original JPEG byte-for-byte for everyone else from the same stored artifact.

For product teams, the honest read on screenshots and docs is that AVIF handles them poorly — ringing around text, color banding on gradient backgrounds — and WebP isn't dramatically better. If you ship a docs site with lots of UI screenshots, JXL for Safari plus PNG for everyone else is probably a better combo than AVIF-everywhere, and Archibald's data backs that.

Looking ahead

The Chromium position on JXL has not softened publicly, but the political ground is shifting: Apple shipping it in both Safari and system frameworks means a non-trivial slice of the web now gets JXL whether Google likes it or not, and that slice generates the kind of real-world usage data Google originally said was missing. Archibald's post reads less like advocacy and more like a receipt — the numbers the ecosystem was told to go produce, now produced. Whether that moves Chromium is a different question, but for engineers choosing what to ship this quarter, the choice is no longer AVIF-or-nothing. It's AVIF for the photos, JXL for everything else, and a `` tag to glue the two together.