⏱️ Lectura: 10 min
Chrome rejected JPEG XL in 2023, and in 2026 perceptual compression metrics still support that decision. A new decoder written in Rust arrived, with varying degrees of support, in Firefox and Chrome, reviving the debate over whether the codec deserves a place on the Web.
📑 En este artículo
Compression engineer Gianni Rosato, who contributed to AVIF encoder improvements and now develops his own video codec, published a technical analysis comparing JPEG XL against AVIF and WebP in the scenarios that actually matter in production. This article summarizes those findings with practical examples for anyone choosing which image format to use in their web stack today.
TL;DR
- Chrome removed experimental JPEG XL support in 2023 despite it being a royalty-free codec from the JPEG Committee.
- A JPEG XL decoder written in Rust arrived in Firefox and Chrome in 2026, reducing the risk of memory bugs.
- In lossless mode, JPEG XL is only 11.9% smaller than lossless WebP, measured on a dataset that’s not very realistic for the Web.
- In lossy compression, which accounts for most real web traffic, JPEG XL loses to AVIF according to CVVDP, MS-SSIM, and SSIMULACRA2.
- The reference encoders for AV1 and SVT-AV1 received perceptual tuning through human subjective testing; libjxl hasn’t reached that level.
- JPEG XL lacks directional prediction in its VarDCT blocks (ranging from 2×2 to 256×256 pixels), which costs it edge preservation.
- Splines, JPEG XL’s proposed solution for edge preservation, still don’t have a working proof of concept.
- JPEG XL lacks a real deblocking filter: it only has gaborish and EPF as partial approximations.
What happened to JPEG XL
Chrome removed experimental JPEG XL support in 2023, even though the codec, developed within the JPEG Committee, is royalty-free and had been gaining attention from major companies. The decision sparked controversy among free software advocates, who saw JPEG XL as an open alternative to Google’s outsized influence over image codecs.
In 2026, a JPEG XL decoder written in Rust appeared, reaching Firefox and Chrome to varying degrees. The logic behind it is simple: a decoder written in a memory-safe language reduces the risk of repeating the 2023 incident with WebP, when a critical vulnerability in the libwebp library (CVE-2023-4863) forced emergency patches in Chrome, Firefox, and dozens of applications that depended on that library, including Signal and 1Password.
The question Rosato raises is direct: is a safer decoder enough to justify bringing JPEG XL back to browsers? His answer, backed by compression metrics, is that it’s not enough on its own.
Context and history
JPEG XL was born within the JPEG Committee, with Jon Sneyers and Jyrki Alakuijala as its lead authors. Rosato clarifies in his analysis that he respects both authors’ work and public conduct, and that he even supported JPEG XL’s inclusion in Interop 2024, the browser initiative to unify support for web features. His goal isn’t to discredit the authors, but to offer an empirical look at the state of image compression in 2026.
The discussion around JPEG XL has always been loaded with symbolism. For much of the free software community, the codec represented an open alternative to Google’s outsized influence over the formats ecosystem, where WebP and AVIF have strong backing from the Alliance for Open Media. That symbolism, according to Rosato, shouldn’t replace technical analysis when deciding which format actually serves the Web.
Technical details and JPEG XL performance
JPEG XL divides an image into VarDCT blocks ranging from 2×2 to 256×256 pixels and transforms them into frequency representations, a scheme in the same spirit as classic JPEG but with variable block sizes. What it’s missing, according to the analysis, are directional prediction modes: the technique codecs like WebP and AVIF use to predict a block’s pixels from neighboring blocks, subtract that prediction from the actual pixels, and transform only the difference. That technique preserves image edges better.
JPEG XL’s proposed solution to compensate for that gap is splines, mathematical curves designed to represent edges. The problem lies in the encoder: it needs an algorithm that detects which pixels can be represented as a spline and then decides, using rate-distortion optimization, whether encoding them that way makes sense. Rosato points out that no proof of concept using splines for edge preservation exists yet, nor is there any reason to believe they would outperform directional prediction.
JPEG XL also lacks a dedicated deblocking filter, the tool that removes visible artifacts between adjacent blocks. Instead, it uses two partial filters: gaborish, JPEG XL’s closest equivalent to AV1’s restoration filter, and EPF (edge-preserving filter), which attempts to preserve edges. Neither one fully replaces a real deblocking filter.
| Codec | When to use it | Advantage | Limitation |
|---|---|---|---|
| JPEG XL | Lossless photo archiving, professional workflows | ~11.9% smaller than lossless WebP | Not competitive in lossy compression; limited browser support |
| AVIF | Web photos and illustrations, most use cases | Better fidelity per bit in lossy compression (CVVDP, SSIMULACRA2) | Slower encoding than classic JPEG |
| WebP | Broad compatibility, simple animations | Universal browser support for years | Falls behind AVIF on modern perceptual metrics |
The metrics back up that gap. CVVDP and SSIMULACRA2 are perceptual metrics designed to approximate how the human eye evaluates compression artifacts, more reliable than classic metrics like PSNR when comparing modern codecs. The AV1 reference encoder received perceptual tuning based on controlled subjective testing with human viewers, and SVT-AV1 offers similar tuning modes. libjxl, JPEG XL’s reference encoder, hasn’t reached that level of tuning, according to Rosato, who uses Halide Compression’s experimental aperture-alpha encoder as a reference for how much ground is still left to cover.
💭 Key point: there’s no such thing as a codec benchmark, only an encoder benchmark: JPEG XL’s theoretical ceiling as a format could be higher than what libjxl achieves today in practice.
flowchart LR
A["Original image"] --> B["VarDCT blocks (2x2 to 256x256 px)"]
B --> C["Frequency transform"]
C --> D["Gaborish and EPF filters"]
D --> E["JPEG XL bitstream"]
How to test it yourself
Checking this difference requires nothing more than a terminal. libjxl, the reference implementation of JPEG XL, includes the cjxl (encoder) and djxl (decoder) tools.
# Windows (with Scoop)
scoop install libjxl
# macOS (with Homebrew)
brew install jpeg-xl
# Linux (Debian/Ubuntu)
sudo apt install libjxl-tools
With these tools installed on any of the three systems, you can now encode and decode JPEG XL files from the command line.
# Encode a PNG image to JPEG XL with true lossless compression
cjxl input.png output.jxl --distance=0
# Decode back to PNG to compare visually
djxl output.jxl output_decoded.png
# Compare file sizes
ls -la input.png output.jxl
The --distance=0 flag activates JPEG XL’s true lossless mode. By comparing that result against a lossless WebP generated with cwebp -lossless input.png -o output.webp, you can check on your own image whether that 11.9% difference holds up.
Browser support is still inconsistent across versions. In Chrome, the experimental flag appears under chrome://flags by searching for “jxl”; in Firefox, under about:config by searching for image.jxl.enabled, although that flag’s availability varies by version and channel (stable, beta, nightly). Before relying on JPEG XL in production without a fallback format, check the updated compatibility matrix.
⚠️ Heads up: no major browser supports JPEG XL stably and universally in 2026. Using it in production today without a <picture> element with fallback formats (AVIF, WebP) breaks the image for a large share of visitors.
Impact and analysis
For the vast majority of image traffic on the Web (product photos, banners, illustrations, page backgrounds), what matters is lossy compression, not lossless. There, JPEG XL doesn’t win. The format’s actual advantage, that 11.9% in lossless mode, was also measured on a dataset that’s not very representative of the Web: 157-megapixel photos, 10-megapixel illustrations, and 27-megapixel scanned books, far beyond what any site actually serves to an end user.
The security argument isn’t enough on its own either. The fact that the new decoder is written in Rust reduces the risk of a memory vulnerability like the one in libwebp in 2023, but that justifies a safer decoder, not necessarily the mass adoption of an entire format with its full encoding surface and use cases.
For developers in Latin America choosing an image format for a site or app today, the practical advice is simple: AVIF for lossy compression wherever the browser supports it, WebP as a universal fallback, and JPEG XL only in specific workflows where lossless matters: professional photography, digital archiving, printing. Not as a general-purpose format for the Web.
What’s next
Halide Compression is working on Aperture, the codename for its next encoder, whose test binary (aperture-alpha) Rosato uses as a reference for how far libjxl still has to go to compete at the perceptual efficiency frontier. If some JPEG XL encoder closes that gap, the discussion about including it in browsers could reopen with different arguments.
Meanwhile, the Rust decoder will keep expanding in Firefox and Chrome, reducing the risk if more sites start serving JPEG XL for specific cases, without that implying a general adoption of the format to replace AVIF or WebP.
📖 Summary on Telegram: View summary.
Try it yourself: install cjxl and djxl from libjxl, encode one of your own images losslessly, and compare it against a cwebp -lossless output to see whether that 11.9% holds up in your own case.
Frequently Asked Questions
Will Chrome natively support JPEG XL in 2026?
There’s no confirmed official commitment. Chrome keeps the Rust decoder at different stages depending on the version, but that doesn’t equate to stable native support for all users. Check the compatibility matrix before relying on the format in production.
Is JPEG XL better than AVIF for photos?
In lossy compression, which is the dominant use case on the Web, analyses using CVVDP, MS-SSIM, and SSIMULACRA2 metrics show AVIF ahead. JPEG XL’s advantage only shows up in lossless mode.
What is SSIMULACRA2?
It’s an image perceptual quality metric designed to approximate how the human eye evaluates compression artifacts, more accurate than classic metrics like PSNR for comparing modern codecs.
What does this have to do with the 2023 WebP vulnerability?
In 2023, a critical flaw in the libwebp library (CVE-2023-4863) affected Chrome, Firefox, and dozens of applications. The renewed interest in a Rust-based JPEG XL decoder aims to prevent a similar bug in C or C++ from massively compromising browsers again.
Should I use JPEG XL on my website today?
For the general case (product photos, banners, blog images), prioritize AVIF with WebP as a fallback. JPEG XL makes sense in photography or archival workflows where lossless mode is a genuine requirement.
What is libjxl?
It’s the reference implementation of JPEG XL, which includes the cjxl (encoder) and djxl (decoder) command-line tools, maintained on GitHub.
References
- The Case Against JPEG XL, by Gianni Rosato: the original technical analysis comparing JPEG XL against AVIF and WebP.
- libjxl repository on GitHub: reference implementation of JPEG XL, with the cjxl and djxl tools.
- JPEG XL on Wikipedia: history and general specification of the format.
- CVE-2023-4863 in the NVD: the libwebp vulnerability that exposed Chrome, Firefox, and other applications in 2023.
- Image file type and format guide on MDN: compatibility and usage reference for image formats on the Web.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
0 Comments