Why JPEG XL Still Doesn't Belong in Web Browsers

The Web's Image Format Debate Heats Up

In September 2026, image-compression engineer Gianni Rosato published a detailed technical critique of JPEG XL as a Web codec, reigniting a debate that many thought had settled when Chrome rejected the format in 2023. Rosato, who has contributed to AV1 and AVIF encoding, argues that while JPEG XL is technically impressive and has a place outside the Web, it fails to meet the specific needs of browsers—particularly when compared to modern AVIF and WebP implementations.

The timing is notable: a Rust-based JPEG XL decoder has recently made its way into Firefox and Chrome, raising questions about whether the Web's major stakeholders are reversing course. Rosato's piece, titled "The case against JPEG XL," offers an empirical counterpoint grounded in encoder benchmarks and format architecture, not just political or ideological arguments.

The Lossless Advantage Is Overstated

One of JPEG XL's most celebrated features is its lossless compression. However, Rosato points out that the format's lossless advantage over WebP is only about 11.9% smaller—and that figure comes from a test dataset of extremely large images (157 MP photos, 10 MP illustrations, and 27 MP books) that are far from typical Web content.

"The average Web consumer doesn't need lossless; they just need a lossy codec versatile enough to prevent terrible artifacts," Rosato writes. Given the small volume of truly lossless-critical content on the Web, he argues the cost of adding a new codec to browsers isn't justified by such a marginal gain.

Lossy Compression: AVIF Has Taken the Lead

When JPEG XL was first proposed, its reference encoder was considered more perceptually optimized than competitors. But Rosato argues that's no longer the case. The AV1 reference encoder and SVT-AV1 have both received specialized perceptual tuning based on subjective human trials, closing any gap that once existed.

Rosato's own benchmarks, using metrics like CVVDP, MS-SSIM, and SSIMULACRA2, show AVIF outperforming JPEG XL across the fidelity range. He also highlights structural disadvantages in JPEG XL's design:

• No directional prediction: Unlike WebP and AV1, JXL lacks directional prediction modes, which help preserve edges and save bits in block-based coding.
• Weak deblocking: JXL's in-loop filters (gaborish and EPF) aren't equivalent to a proper deblocking filter, leading to mosquito noise.
• Awkward patch coding: For non-photographic images, JXL's patch mechanism is far more complex and less efficient than AV1's Intra Block Copy, requiring extra frames, layers, and blending logic.

Rosato also notes that JXL's perceptual XYB colorspace, while innovative, relies on aggressive quantization of the B channel, resulting in subpar color preservation that encoder developers must explicitly work around.

Decode Time: A Critical Weakness

Decode speed is where JPEG XL falls most dramatically behind. Rosato's size-matched comparisons show WebP decoding over 10x faster than jxl-rs, even when the WebP file is 90KB larger. AVIF, despite its reputation as slow, also outperforms JXL in decode time.

More concerning are pathological cases. Rosato demonstrates a 1,918-byte JXL image that takes 17.43 seconds to decode on an M5 Pro using the Rust decoder. As this decoder makes its way into Chrome and Firefox, such images could become trivial denial-of-service tools for low-end devices. "You can already ship a couple dozen of these on a Web page and slow Apple devices down," he warns, noting Safari's native JXL support.

Progressive Rendering and JPEG Recompression

JPEG XL's progressive rendering, once a selling point, is now matched or exceeded by AVIF. Rosato points to a demo on the JPEG XL info site itself showing AVIF delivering a usable image at just 2-3% of the file size, while JXL lags. He also notes that JXL's progressive decode isn't even natively supported in Safari, requiring a polyfill.

JPEG recompression—converting existing JPEGs to JXL losslessly—saves about 20% in size but costs roughly 33% more decode time. "The argument that the savings come 'for free' is misleading," Rosato says, especially on the Web where decode speed directly impacts user experience.

The Politics of Codec Choice

Rosato acknowledges the political dimension: JPEG XL came from Cloudinary and Google, and its rejection by Chrome in 2023 was seen by many as a blow against open formats. But he argues that much of the support for JXL stems from a desire for more browser choice rather than technical superiority.

"It is my opinion that most of the argument for JPEG XL comes from wanting a Web with more developer choice as opposed to wanting a technologically superior image codec," he writes, while emphasizing that JXL still has a bright future outside the Web—in professional photography, camera hardware, and as a universal interchange format.

The Verdict: A Great Format, but Not for the Web

Rosato's conclusion is clear: JPEG XL's broad, unscoped design is a liability for the Web, which needs codecs that are purpose-built, efficient, and narrowly scoped. AVIF, despite its container quirks, benefits from the mature AV1 ecosystem and now dominates the entire fidelity range.

"JPEG XL isn't useless; it is genuinely compelling technology for use cases beyond the Web. I'm just not personally convinced we need it in browsers any time soon," he concludes. As the Rust decoder integration proceeds, this technical case will likely shape the ongoing debate about which formats deserve a permanent place in the Web platform.