Chrome 155 ships JPEG XL decoding, built on a Rust decoder for memory safety

Chrome 155 decodes JPEG XL

Google's Chrome team has announced that, starting with version 155, the browser can decode images in the JPEG XL format (.jxl). According to the Chrome for Developers blog post, published October 6, JPEG XL is a next-generation image format aimed at modern web and photography workflows. Its headline claims: compression gains of 30–50% over legacy JPEG, lossless modes, built-in HDR support, lossless transcoding of existing JPEG files, and progressive decoding.

The Chrome team frames this not as a winner-take-all decision. Their recommendation is to test both AVIF and JPEG XL and choose per use case. They expect JPEG XL to prove most useful where photographs need high-fidelity or lossless compression, or where progressive rendering is preferred.

Why Rust

Image decoders sit on one of the most attacked surfaces in a browser: they parse complex, untrusted binary structures straight from the network, and they run inside the renderer process. The post notes that decoders written in memory-unsafe languages such as C++ have historically been prone to out-of-bounds reads, heap overflows and use-after-free bugs.

Chrome's existing defenses — sandboxing, defense in depth, and the "rule of two" — treat sandboxing as a secondary layer. To remove that class of bugs at the source, the team integrated jxl-rs, a pure Rust implementation of the JPEG XL decoder.

Making it fast as well as safe

A memory-safe decoder is an easy call when it runs about as fast as the best memory-unsafe alternative; a large performance penalty would not be. Modern codec speed leans heavily on SIMD hardware. To use it, the team needed Rust's target_feature_11 feature to be stabilized, which allows SIMD instructions without unsafe code. On top of that they built jxl_simd, a SIMD abstraction layer inspired by Highway, the C++ library originally developed for libjxl, the reference JPEG XL implementation. The result is a cross-platform library that keeps SIMD optimizations while confining unsafe operations to a small number of carefully reviewed spots.

The post also describes a generic processing pipeline for steps that cross region boundaries, designed to minimize data copies and keep hardware fully utilized. Performance across hardware platforms is tracked publicly on the jxl-rs performance dashboard. The implementation was reviewed with fuzzing and AI-assisted code review, and the team reports that no memory errors were found across the implementation's history — evidence, they argue, of what Rust brings to memory safety.

How the decision happened

Chrome says its decision to support JPEG XL came from developer feedback gathered through bug reports, surveys, the Developer Signals Project and the Interop Project, where JPEG XL was a popular proposal in 2026 and in the years before. To make the format work across browsers, the team took part in the Interop 2026 JPEG XL Investigation, which tests JPEG XL features in browsers; per the post, Chrome passes those tests.

The blog closes with a recommendation that developers, content creators and platform owners start putting .jxl images and animations into their pipelines and report bugs. The acknowledgements credit Helmut Januschka for contributions to both the Chrome integration and jxl-rs, along with Martin Bruse, Zoltan Szabadka, Sami Boukortt and Wonwoo Choi for their work on jxl-rs itself.

Why it matters

Native decoding in the browser has always been the biggest obstacle for any new image format, and Chrome shipping support by default is the step that turns JPEG XL from an experiment into something sites can realistically serve. The practical payoff is payload: substantially smaller photographs than JPEG at similar quality, plus lossless JPEG recompression, which means large existing photo libraries can shrink with no quality loss at all. The engineering approach matters too — demonstrating that a memory-safe Rust decoder can hit codec-level speed without unsafe code could shape how browsers build image and media parsers going forward.