Glonce

JPEG XL still trails AVIF and risks stalling low-end devices, argues a former proponent

toolsThe Glonce editorsHacker News🔥61Glonce rating61Impact45Novelty35Relevance70Surprise45Players50Credibility75

JPEG XL, the royalty-free image codec from the JPEG Committee, was rejected from Chrome in 2023 despite being widely seen, including by this piece's author, as a clear upgrade over JPEG, more versatile than WebP, and well suited to use cases beyond the web. A blog post argues that little has changed to justify adding it to the web specifically, even though a new JPEG XL decoder written in Rust has recently reached Firefox and Chrome in some capacity, a development some read as browsers reversing course, partly on the idea that the new decoder could guard against a repeat of 2023's WebP security vulnerability. The author treats that idea as speculation, saying browsers 'may' be reversing course rather than stating it as settled fact, and argues the technical case for adding JPEG XL to the web has not actually improved.

The post is written by a compression engineer with direct experience in the field. They worked on an AV1 encoder and, together with Julio Barba, made what they call significant advancements to AVIF. They say they were previously a big proponent of JPEG XL for all use cases, endorsed it for the Interop 2024 web-compatibility initiative, and have personally interacted many times with two of JPEG XL's primary authors, Jon Sneyers and Jyrki Alakuijala, praising their public conduct and technical skill. The author states upfront that the piece is not meant to discredit JPEG XL's authors or take a political stance on the format. When the author later built an image encoder of their own, they chose not to support JPEG XL in it.

The technical case starts with lossless compression, JPEG XL's most cited advantage. In practice, the author says, JPEG XL's lossless files come out only about 11.9% smaller than lossless WebP files, and that figure is measured on a dataset the author calls unrealistic for the web: images of 157 megapixel photos, 10 megapixel illustrations and 27 megapixel books. Since most web content only needs versatile lossy compression, the author argues it cannot be worth adding an entire new codec to browsers to save roughly 12% on a small slice of content whose use cases are not especially sensitive to bandwidth anyway. Because JPEG XL is not competitive on lossy compression, in the author's view lossless is its only real remaining advantage.

On lossy compression, the piece argues that modern encoders, tuned using controlled human perceptual trials (both the AV1 reference encoder and SVT-AV1 have such tuning modes), now beat JPEG XL's reference encoder, libjxl, on both speed and fidelity per bit, based on the CVVDP and SSIMULACRA2 perceptual metrics. The author points to specific technical gaps behind that gap: JPEG XL divides images into VarDCT blocks from 2x2 up to 256x256 pixels but has no directional prediction modes the way WebP does, which weakens edge preservation; the proposed fix, splines, is far harder to implement and has no existing proof of concept; JPEG XL has no true deblocking loop filter, only two partial in-loop tools, called gaborish and EPF, that together cannot fully replace one, leaving it prone to mosquito noise; its XYB perceptual colorspace is based on intuition, and its promised gains are undercut because libjxl currently quantizes the blue-yellow channel aggressively, hurting color preservation in a way new JXL encoder developers have to work around; and JPEG XL handles non-photographic images poorly, with a proposed 'patches' fix that is harder to use than AV1's Intra Block Copy tool and currently has performance issues serious enough that libjxl disables patches by default below encoder effort level 7.

Two other claimed JPEG XL advantages fare no better in the piece. Progressive rendering, which shows a rough version of an image before the full file arrives, is also supported by AVIF: per a comparison from the JPEG XL project's own info site, AVIF shows a usable image after only about 2 to 3% of the full image's data has arrived, well ahead of JPEG XL, while also producing the smaller file overall. The author adds that AVIF's progressive decode currently works only through Chrome's native decoder, while JPEG XL relies on a polyfill and does not support progressive decode even in Safari. Separately, JPEG recompression, the ability to losslessly convert an existing JPEG into JPEG XL, is often cited as saving about 20% in file size, but the author says that saving costs roughly 33% longer decode time, which undercuts the idea that it comes for free.

Decode time is where the piece is most pointed. In one test using four size-matched encodes of the same source image (JPEG at 2,478,828 bytes, JPEG XL at 2,599,428 bytes, AVIF at 2,649,949 bytes and WebP at 2,693,794 bytes), WebP, despite being more than 90 kilobytes larger than the JPEG XL file, decoded more than ten times faster than the Rust JPEG XL decoder. Because JPEG XL's bitstream is flexible enough to be crafted adversarially, the author links to a 'prime wall' test image, just 1,918 bytes, that forces the decoder to compute prime numbers up to 33,599; it took 17.43 seconds of user time to decode on the author's own M5 Pro machine using the Rust decoder. The author warns this makes it trivially easy to JXL-bomb low-end devices as the new decoder spreads, and that a page could already ship a couple dozen such tiny images to slow down Apple devices, since Safari already supports JPEG XL natively.

The author's overall position is that web image codecs should be purpose-built and narrowly scoped. They see AVIF's adoption as effectively settled given the maturity of the AV1 ecosystem, despite some rough edges in its container format and parts of the AV1 spec, and say WebP was a bit too narrowly scoped but pointed in the right direction. JPEG XL, by design, aims to serve nearly every use case rather than the web specifically, and the author concludes they do not see how JPEG XL is even as good a fit for the web as WebP, warning that adding it would mean climbing another compatibility hill on top of the one the web already climbed to get WebP broadly adopted.

Key facts

  • JPEG XL's lossless files are only about 11.9% smaller than lossless WebP files in practice, measured on a dataset of 157 megapixel photos, 10 megapixel illustrations and 27 megapixel books that the author calls unrealistic for the web.
  • Modern lossy encoders now beat JPEG XL's reference encoder, libjxl, on both speed and fidelity per bit, according to the CVVDP and SSIMULACRA2 perceptual metrics.
  • In a size-matched decode test of the same image (JPEG 2,478,828 bytes, JPEG XL 2,599,428 bytes, AVIF 2,649,949 bytes, WebP 2,693,794 bytes), WebP decoded more than ten times faster than the Rust JPEG XL decoder despite being the largest file.
  • A deliberately crafted, 1,918-byte JPEG XL 'prime wall' image took 17.43 seconds of user time to decode on the author's M5 Pro, which the author says makes JXL-bombing low-end devices trivially easy.
  • The author, who endorsed JPEG XL for Interop 2024 and has interacted personally with two of its authors, concludes they do not see JPEG XL as even as good a fit for the web as WebP.

Why it matters

JPEG XL was rejected from Chrome in 2023 even though many technologists, including this piece's author, saw it as a clear step up from JPEG and more versatile than WebP. That debate has resurfaced because a new JPEG XL decoder written in Rust has recently reached Firefox and Chrome in some capacity, which some read as browsers reconsidering the format, partly on the theory that a memory-safe decoder could avoid a repeat of 2023's WebP security bug. The author treats that theory as speculation, not a settled reason to ship JPEG XL, and argues the technical case for adding another major image codec to browsers has not actually improved since 2023. Because a format that lands in Chrome, Firefox and Safari becomes a long-term commitment for the whole web platform, the argument matters well beyond one blog post: it decides whether the web takes on JPEG XL's added complexity for a lossless gain the cited paper measures at roughly 11.9%, or holds the line with the AVIF and WebP encoders already shipping.

Who it affects

Web developers and site owners who choose image formats sit at the center of this, since whichever codec browsers standardize on becomes their default choice. Browser vendors, especially Chrome and Firefox, are the direct audience, since they are the ones deciding whether to move JPEG XL decoding from limited support into a full, user-facing feature. Encoder and decoder developers working on libjxl, libavif and the new Rust-based JPEG XL decoder are directly implicated, as are JPEG XL's own authors, Jon Sneyers and Jyrki Alakuijala, whose design choices the piece scrutinizes in detail even as it praises them personally. The piece also argues that owners of low-end and older devices, including Apple hardware that already supports JPEG XL natively in Safari, are exposed if adversarial JPEG XL images start showing up on ordinary web pages.

How to use it

JPEG XL is royalty-free and already supported natively in Safari, though the author notes its progressive decode does not work even there. A Rust-based JPEG XL decoder has recently landed in Firefox and Chrome in some capacity, short of full native support. On the economics of adopting it now, the piece's read is mixed at best: losslessly recompressing an existing JPEG into JPEG XL is often pitched as saving about 20% in file size, but that saving costs roughly 33% longer decode time, so it is not free the way it is sometimes advertised, and JPEG XL's clearest edge, smaller lossless files, only reaches about 11.9% over lossless WebP, on very large images unlike most ordinary web content. In effect, the author's practical recommendation is to keep using well-tuned AVIF or WebP encoders rather than wait for or prioritize JPEG XL.

How solid is it

The author writes from direct compression-engineering experience: they worked on an AV1 encoder, contributed with Julio Barba to what they call significant advancements to AVIF, and later built an image encoder of their own, choosing not to support JPEG XL in it. They disclose their own history as a big proponent of JPEG XL who endorsed it for Interop 2024, which cuts both ways: it shows the reversal is considered rather than reflexive, but it also means the author has a stake in the encoder landscape they are judging. The piece backs its central claims with named perceptual metrics, CVVDP and SSIMULACRA2, and reproducible numbers, exact file sizes and decode times for a size-matched set of JPEG, JPEG XL, AVIF and WebP files, rather than resting on description alone. Even so, the author labels the piece's own final section 'Conclusion and Opinion', some figures are given without stating their exact baseline, such as what the roughly 33% longer recompression decode time is measured against, and the piece carries a byline, Gianni Rosato, who links his own compression work to his company, Halide Compression, so its claims can be checked against a named author and affiliation.

Risks and caveats

The most concrete risk the author raises resembles a denial-of-service attack: because JPEG XL's bitstream is flexible enough to be crafted adversarially, a test image the author links to, just 1,918 bytes, forces the decoder to compute prime numbers and took 17.43 seconds of user time to decode on their own machine. The author warns this makes it trivially easy to JXL-bomb low-end devices as Rust-based JPEG XL decoding spreads to more browsers, and that a page could already ship a couple dozen such tiny images to slow down Apple devices today, since Safari already decodes JPEG XL natively. The piece is also, by design, an argument rather than a neutral survey: only its final section is framed as the author's own opinion, some of its comparisons, such as calling a dataset of 157 megapixel, 10 megapixel and 27 megapixel test images unrealistic for the web, rest on the author's own judgment of what counts as realistic, and the claim that browsers may be reversing course on JPEG XL is explicitly speculative rather than confirmed by any browser vendor.

“the prime wall image is just 1,918 bytes, so it's about to become trivially easy to JXL-bomb low-end devices.”

— the blog post's author