A Former Advocate Makes the Technical Case Against JPEG XL on the Web

JPEG XL is a genuinely strong image format—royalty-free, versatile, and a clear improvement over legacy JPEG—but a compression engineer who once championed it now argues it doesn’t belong in browsers. Chrome dropped support in 2023 to widespread frustration, and the recent arrival of a memory-safe Rust decoder in Firefox and Chrome has reignited hopes of a reversal. The author, who works on AVIF and AV1 encoding and personally knows JXL’s creators, says a safer decoder isn’t a good enough reason to standardize the format for the Web.

The core objection is that the Web overwhelmingly runs on lossy compression, and that’s exactly where JPEG XL is weakest. Its headline strength is lossless coding, but that only beats lossless WebP by roughly 12% on an atypical, high-resolution test set—far too little payoff for a low-bandwidth-sensitivity use case to justify adding a whole new codec. On lossy quality, modern AV1-based encoders (libaom, SVT-AV1) have pulled ahead on both speed and fidelity per bit after perceptual tuning validated by human trials, and strong perceptual metrics like SSIMULACRA2 and CVVDP show libjxl trailing the frontier.

The author frames many of these gaps as structural rather than just implementation immaturity. JPEG XL lacks directional prediction and any true deblocking loop filter, its XYB colorspace over-quantizes the blue channel at the cost of color accuracy, and it handles non-photographic content poorly. The proposed workarounds—splines for edge preservation, patches and layer/blend machinery to mimic AV1’s Intra Block Copy—are far harder to implement well and carry heavy bitstream overhead. The takeaway: the format’s theoretical ceiling may be high, but closing the distance in practice is a much harder problem than its symbolic status in free-software circles suggests.