Chrome 155 decodes JPEG XL, and the decoder is written in Rust

Your image pipeline already spits out three files per photo plus a fallback for the fallback. Bad news: there's a new contender for a slot. Good news: this one might actually earn it.

Chrome is shipping decoding support for JPEG XL (.jxl) starting from Chrome 155, according to an October 6 post on Chrome for Developers by Luca Versari, Moritz Firsching and Philip Jägenstedt. The pitch in the post is short: 30-50% better compression than JPEG, lossless compression, built-in HDR support and lossless JPEG transcoding. That last item is the sleeper. If your CMS is sitting on a decade of old JPEGs, transcoding them without losing a single pixel is a very different conversation from re-encoding and squinting at the artifacts.

And no, nobody is telling you to bin AVIF. The authors recommend "trying both AVIF and JPEG XL to get the best results," and expect JPEG XL to help most with high-fidelity or lossless compression, especially of photographic images, or where fine-grained progressive decoding is preferred. So it's a tool for a job, not a replacement for everything.

The bit that actually got me

Image decoders chew on untrusted binary straight off the network, inside the renderer process. The post calls them one of the most targeted attack surfaces in a browser, and C++ decoders have a long history of out-of-bounds reads, heap overflows and use-after-free bugs. So Chrome integrated jxl-rs, a pure Rust implementation of the JPEG XL decoder.

Speed didn't get traded away for it, either. The Rust target_feature_11 feature had to be stabilized so SIMD instructions could run without unsafe code, and the team built a SIMD abstraction layer, jxl_simd, inspired by the C++ Highway library. The post says fuzzing and AI review of the code found no memory safety bugs across the implementation's entire history. I've read enough image-codec security advisories to find that genuinely moving. A new format lands in a browser and the story isn't a CVE.

(Quick detour: the post credits the Interop Project, where JPEG XL was a popular proposal in 2026 and for several years before. Chrome also joined the Interop 2026 JPEG XL Investigation to get test coverage for all of the format's features in browsers. OK, back.)

The post covers Chrome only and says nothing about other engines. So .jxl goes in a <picture> element as one <source> among several, with a format every browser you support already decodes as the fallback. The browser takes the first source it can handle and skips the rest, which is exactly the job <picture> was built for.

Verdict: a 7 for the format news until more engines weigh in, and a 9 for shipping a decoder in a memory-safe language.