Compression engineer argues JPEG XL's lossless edge and lossy performance don't justify Web browser adoption

The author frames this as a reversal. They had endorsed JPEG XL for Interop 2024 and worked alongside its primary authors, but after building their own, concluded the format does not have a Web role. The piece is structured as an empirical case rather than a political one: the author explicitly disclaims any intent to attack the format's authors or its symbolism in free software. That framing matters because the JPEG XL debate has been as much about standards politics as about pixels per byte, and the author is deliberately stepping around the politics to argue on measurements.

The lossless argument is the load-bearing one for JPEG XL on the Web, and the author attacks it head-on. Lossy covers almost all Web use cases by volume, which removes the only scenario where lossless matters. Within that small residual, lossless JPEG XL beats lossless WebP by only roughly 11.9%, measured on a dataset the author flags as unrealistic for the Web (157 MP photos, 10 MP illustrations, 27 MP books). A 12% saving on a tiny, bandwidth-insensitive slice of content is the author is not enough to justify shipping a new codec, parsing path, and content-type negotiation. That collapses the strongest historical argument for JPEG XL.

On lossy compression, the author argues the field has moved. The original case for JPEG XL rested on a reference encoder that was unusually well tuned to perceptual quality for its time. Since then, AV1 has been tuned with controlled subjective human trials, SVT-AV1 has similar perceptual modes, and libaom now ships a perceptually optimized mode (tune IQ) within a couple of points of its metric-optimized mode. The author benchmarks against an upcoming Halide encoder (codenamed Aperture) and finds JPEG XL well behind on SSIMULACRA2-style metrics. The piece also notes that the libjxl reference encoder has historically had perceptual issues that remain largely unresolved, weakening the 'great perceptual tuning' reputation.

There is also a structural argument. JPEG XL uses VarDCT blocks without directional prediction modes, while block-based codecs like WebP let a block be predicted from surrounding pixels before the frequency transform. Directional prediction can blur in a poorly tuned encoder, but a strong mode-decision pipeline can pick the right mode. The author argues this leaves libjxl with more ground to recover than is realistic, because catching up is not just encoder tuning but a format-level capability gap. The caveat the author raises themselves applies here: there is no such thing as a codec benchmark, only an encoder benchmark, so a sufficiently clever future encoder could in principle close the gap. The author does not claim that is impossible, only that it is unlikely enough to matter for a Web deployment decision.

The timing is the part an engineer reading this should hold onto. A JPEG XL decoder in Rust has reached Firefox and Chrome in some capacity, which is precisely what the 2023 rejection stalled on. The article exists because the author wants the case against JPEG XL to be on the record before browser vendors treat the decoder landing as a reason to ship the format. The empirical numbers, the directional-prediction critique, and the lossless-margin argument are the three things to weigh against any vendor announcement about re-enabling JPEG XL. None of the feeds added material beyond pointing at the piece, so the argument above is sourced entirely to the lead article.