Chrome 155 Turns On JPEG XL by Default With a Rust Decoder While Firefox Waits for 158

Chrome now decodes JPEG XL images without a flag. Starting with Chrome 155, support is on by default, according to a Chrome for Developers post dated October 6, 2026 and credited to Luca Versari, Moritz Firsching and Philip Jägenstedt.

The decoder is jxl-rs, a pure Rust implementation of the format. Chrome's team says it ran fuzzing and "AI review of the code" and "have not found any memory safety bugs throughout the entire implementation history."

What Chrome 155 changes for image formats

JPEG XL is a still-image format that Chrome lists as supporting lossless compression, built-in HDR, lossless transcoding of existing JPEG files and fine-grained progressive decoding. Chrome's post puts the compression gain at 30 to 50 percent over JPEG. That figure is Google's own, and the post does not say which images or encoder settings produced it.

The post does not tell developers to switch. Its recommendation is to "try both AVIF and JPEG XL to get the best results," and it calls JPEG XL most helpful for high-fidelity or lossless compression of photographs.

For a site owner, the practical task is a <picture> element with a .jxl source ahead of the AVIF one. Chrome 155 will take the first. Browsers without the decoder fall through to the next source, so nothing breaks for them.

Why the decoder is written in Rust

The engineering detail in the post is about avoiding unsafe code. The team stabilised the target_feature_11 Rust feature so SIMD instructions can be used without an unsafe block. It then built jxl_simd, an abstraction layer the post describes as inspired by Google's Highway library.

Speed was checked on a public performance dashboard covering several hardware platforms. The post names five further contributors: Helmut Januschka, Martin Bruse, Zoltan Szabadka, Sami Boukortt and Wonwoo Choi.

Image decoders parse untrusted files from any web page, which is why the language matters. Our Python 3.15 benchmark piece covers a different runtime, and VB6 Studio Web shows another project choosing a browser sandbox over native code. The trade-off is the same one: keep the risky work inside a safe subset.

Where Firefox 158 and Safari stand

Mozilla's plan has slipped. Timothy Nikkel, a Mozilla developer, announced on August 24, 2026 that JPEG XL would be on by default in Firefox 157. On September 3 he updated the thread: "JPEG XL decoding will be enabled by default in the 158 train rather than the 157 train."

His reason: "The remaining work took longer than I estimated, and I'd rather give it the time it needs than hold to the original schedule." Firefox also uses jxl-rs and keeps the image.jxl.enabled preference, plus a Firefox Labs checkbox.

Browser	JPEG XL status	Decoder
Chrome 155	On by default	jxl-rs (Rust)
Firefox 157	Firefox Labs checkbox only	jxl-rs (Rust)
Firefox 158	Default planned, per Mozilla	jxl-rs (Rust)
Safari	Implemented in 2023 without progressive rendering, per PiunikaWeb	Not covered in these sources

The Safari row rests on PiunikaWeb's August 25 report, which also says Mozilla required the format to be rewritten from C++ into Rust before inclusion. We did not find Apple's own statement.

What is still unknown

Chrome's post gives no date for a stable Chrome 155 release in these sources and no usage numbers. It also does not say whether Google's Rust decoder matches the older C++ reference decoder on every edge case.

The next checkpoint is the Firefox 158 release. Until it ships, a JPEG XL file works by default in Chrome 155 and later, and in Firefox only for people who tick the Labs box.