JPEG XL vs AVIF in 2026: Chrome Is Back, Who Wins?

Chrome 155 shipped this week with JPEG XL support restored — built on a new Rust decoder — ending the format’s two-year exile from the world’s most-used browser. Firefox 157 did the same in September. For the first time, all four major browsers support JPEG XL, and the image format wars are back in the conversation. But a comprehensive October 2026 benchmark by web performance engineer Jake Archibald already has an answer: AVIF is still the right default for web delivery, with one significant exception.

Chrome 155 Changes the JPEG XL Coverage Math

Google infamously pulled JPEG XL from Chrome in 2022, citing low ecosystem adoption — a move that drew outrage from a vocal contingent of developers who considered the format technically superior. The new Chrome 155 implementation rewrites the decoder in Rust and arrives within weeks of Firefox 157 enabling JPEG XL by default. Safari has supported it since 2023. Today, all four major browsers decode JPEG XL.

However, “all major browsers support it” and “you should ship it” are not the same statement. AVIF still carries roughly 94-96% global browser coverage accumulated over five years of deployment. JPEG XL’s effective reach before Chrome 155 was around 12-15% — Safari alone. The new Chrome and Firefox support will push that number meaningfully upward over the next six months as update rollouts complete, but it will not close the gap overnight. Meanwhile, AVIF wins on compression for the scenarios that represent the vast majority of web image delivery.

AVIF vs JPEG XL: What the 2026 Benchmark Data Shows

Archibald’s methodology is rigorous — current encoder versions, SSIMULACRA2 perceptual quality metrics, a MacBook M4 Pro, and multiple image types. Importantly, he tests both major JPEG XL encoders: the reference libjxl and the newer jixel. This distinction matters because benchmarks using only libjxl make JPEG XL look worse than it actually is.

Even with jixel, AVIF wins for photographs by 6-17% at equivalent perceptual quality. For screenshots and UI illustrations — the kind of images SaaS documentation sites serve constantly — the gap widens to 23-89% in AVIF’s favor. Transparent images reveal a critical jixel flaw: it always encodes alpha channels losslessly, producing files 1.9 to 3.1 times larger than AVIF’s lossy alpha approach. For product images on transparent backgrounds, this is a real production concern. The one domain where JPEG XL wins decisively and without asterisks: lossless compression, where AVIF files run 40-122% larger than libjxl JPEG XL.

The Lossless Case: Switch to JPEG XL Now

JPEG XL offers a capability no other format matches: lossless JPEG transcoding. Convert an existing JPEG to a .jxl file and it becomes 9-20% smaller — with identical pixels. When decoded, the output is bit-for-bit equivalent to the original JPEG. For news organizations, stock photo platforms, and e-commerce operations with large JPEG archives, this is immediately actionable regardless of browser coverage, because storage and CDN bandwidth are server-side concerns.

For teams serving design assets, UI component libraries, or documentation screenshots as lossless images, the switch to libjxl JPEG XL is the right call today. A 30% reduction in lossless image storage does not require waiting for browser update cycles. AVIF’s 94% browser coverage is irrelevant here — the format decision for lossless archival is about storage efficiency, not rendering.

What to Actually Ship Right Now

For general web delivery, the answer is a three-layer <picture> element that offers JPEG XL to the browsers that just gained support, AVIF as the primary fallback covering 94% of users, and JPEG for everyone else:

<picture>
  <source srcset="image.jxl" type="image/jxl">
  <source srcset="image.avif" type="image/avif">
  <img src="image.jpg" alt="Description" width="800" height="600">
</picture>

Most major CDNs — Cloudflare, Fastly, ImageKit — already auto-transcode and serve AVIF based on Accept headers. JPEG XL auto-delivery is rolling out to CDN toolchains in the wake of Chrome 155, but check whether your specific CDN supports it yet. If your CDN already handles format negotiation, verify JPEG XL is in the pipeline. If you manage your own build tooling, add the JXL source type now so browsers that understand it can take advantage of the better compression as coverage grows.

One practical note: the quality gap between AVIF and JPEG XL (jixel) narrows significantly at higher encoding efforts. If your pipeline already runs maximum-effort AVIF encoding, the advantage over equivalent-effort JPEG XL drops to 6-15% for photos — meaningful at scale, but not the dramatic gap that default-setting comparisons suggest. Test your specific image types; as the Chrome 155 release notes acknowledge, results vary by content type.

Key Takeaways

• Chrome 155 and Firefox 157 restored JPEG XL — all four major browsers now decode it, ending the format’s two-year coverage limbo
• AVIF remains the right default for lossy web images: 6-17% smaller for photos, 23-89% smaller for screenshots, decisively better for transparent images with jixel’s lossless-alpha limitation
• JPEG XL wins lossless outright — lossless AVIF files are 40-122% larger, making libjxl JPEG XL the correct choice for lossless archives and design asset libraries
• Set up three-layer <picture> elements (JXL → AVIF → JPEG) now so Chrome 155+ and Firefox 157+ users automatically get the smallest files
• If your image archive is primarily JPEGs, JPEG XL lossless transcoding cuts storage 9-20% with identical pixel output — no browser support dependency required