// HACKER NEWS — CYBERSECURITY
The case against JPEG XL
Investigating JPEG XL's place as a Web image codec.
JPEG XL is a technically impressive image codec; it is a definitive upgrade over
JPEG, more versatile than WebP, and well-equipped to serve use cases beyond the
Web. However, it was famously
rejected from Chrome
in 2023. Because this happened to a royalty-free, flexible,
compression-efficient codec from the JPEG Committee that was
receiving attention
from large companies, the decision didn't land well with many.
Recently, a JPEG XL decoder in Rust has made
its way into Firefox and Chrome in some capacity. The Web's major stakeholders
may therefore be reversing course on JPEG XL given that the new decoder may
protect the Web from reliving
2023's WebP vulnerability. Is
this all it took to justify JPEG XL for the Web?
Historically, I've been a big proponent of JPEG XL for all use cases. I
endorsed JPEG XL
for Interop 2024, and I've interacted with Jon Sneyers and Jyrki Alakuijala (two
of the format's primary authors) personally many times. I'm consistently
impressed with their public conduct, level-headedness, technical aptitude, and
passion for the field.
This piece does not seek to discredit the format's authors or their work, nor to
claim any political affiliation relative to the codec's symbolism in free
software. The spirit of this post is educational; I want to offer an empirical
look at the current state of image compression and the Web platform in 2026.
Some inspiration is drawn from
RISC-V: They Should Have Known Better
by Dmitry Grinberg.
I do image compression work, coming from video compression
originally. While working on an AV1 encoder, Julio
Barba and I made
significant advancements to AVIF, and I
learned a lot in the
process. When I decided to start building
my own encoder, I had to think very hard about which
formats I felt had the highest ceilings, could be effectively optimized, and had
the most present and potential utility. I decided not to work with JPEG XL.
By volume, there are very few use cases on the Web that aren't served by
versatile lossy compression. The average Web consumer doesn't need lossless;
they just need a lossy codec versatile enough to prevent terrible artifacts
(e.g. JPEG on non-photographic content). This rules out JPEG XL's lossless
advantage, which in practice is only roughly
11.9% smaller than lossless WebP anyway –
and on an unrealistic test dataset for the Web (157 MP photos, 10 MP
illustrations, and 27 MP books). It cannot be worth bringing a new image codec
to browsers to save 12% on a tiny volume of image content with use cases
inherently less sensitive to bandwidth constraints. I say this because JPEG XL
isn't competitive for lossy, so lossless would be its only real advantage.
One of the original arguments for JPEG XL was that its reference encoder was
more
perceptually optimized
than competing encoders. Now, on both speed and fidelity per bit, other encoders
are stronger.
The AV1 reference encoder received
specialized perceptual tuning based on controlled subjective human trials to
strengthen its efficiency while maintaining a tuning mode optimized for
perceptual metrics. SVT-AV1 has
similar tuning modes. There is no compelling argument that modern encoders
aren't tuned for the human eye.
Metrics aren't perfect, but they paint a daunting picture for JPEG XL: