Glonce

Chrome 155 ships JPEG XL decoding using a Rust decoder, jxl-rs

productsThe Glonce editorsHacker News🔥79Glonce rating79Impact60Novelty70Relevance85Surprise60Players75Credibility95
Chrome 155 ships JPEG XL decoding using a Rust decoder, jxl-rs

In a post on the Chrome developers blog dated October 6, 2026, the Chrome team announced that Chrome is shipping decoding support for the JPEG XL (.jxl) image format starting from Chrome 155. The post describes JPEG XL as a next-generation format for modern web developers and photographers. It claims 30-50% better compression than JPEG, along with lossless compression, built-in HDR support and lossless JPEG transcoding. No test conditions are given for the 30-50% figure.

The authors do not present JPEG XL as a replacement for AVIF. They recommend trying both 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.

Much of the post is about safety. Image decoders are, in the authors' words, among the most critical and targeted attack surfaces in a browser: they parse complex, untrusted binary data from the network inside the renderer process, and decoders written in memory-unsafe languages like C++ have historically suffered out-of-bounds reads, heap overflows and use-after-free bugs. Chrome's security model relies on sandboxing and defense-in-depth, guided by the rule of two, but the post calls sandboxing a secondary layer. To remove the risk at the source, Chrome integrated jxl-rs, a pure Rust implementation of the JPEG XL decoder.

The team also says speed was a design goal: a memory-safe decoder that is approximately as fast as the best non-memory-safe alternative is a much easier choice than one with a significant performance penalty. Using SIMD hardware safely required the target_feature_11 Rust feature to be stabilized, which allows SIMD instructions without unsafe code. The team then built a SIMD abstraction layer, jxl_simd, inspired by the C++ Highway library, which was originally developed for libjxl, the C++ reference implementation of JPEG XL. Together, these let them write a multi-platform library that keeps its SIMD optimizations while confining unsafe operations to a small number of highly vetted locations. Optimizations in jxl-rs build on those in libjxl, including a generic processing pipeline for steps that cross region borders and minimal data copying. Performance across hardware platforms is tracked on the jxl-rs performance dashboard.

The authors say they verified jxl-rs with fuzzing and AI review of the code, and found no memory safety bugs throughout its entire implementation history.

On why Chrome decided to ship, the post says the decision rested on consistent feedback and requests from web developers, most visible in the Interop Process, where JPEG XL was a popular proposal in 2026 and several years before. The team lists bugs, surveys, the Developer Signals Project and the Interop Project among the channels it weighs. For cross-browser interoperability, Chrome took part in the Interop 2026 JPEG XL Investigation, which aims to ensure test coverage for all of JPEG XL's features in browsers and that those tests pass in Chrome.

The post closes by encouraging developers, content creators and platform owners to start using .jxl images and animations in their pipelines, and to file bugs. It thanks everyone who contributed to jxl-rs or its Chrome integration, especially Helmut Januschka for substantial contributions to both, and Martin Bruse, Zoltan Szabadka, Sami Boukortt and Wonwoo Choi for substantial contributions to jxl-rs itself.

Key facts

  • Chrome will decode JPEG XL (.jxl) images starting from Chrome 155, per a Chrome developers blog post dated October 6, 2026.
  • Decoding uses jxl-rs, a pure Rust implementation of the JPEG XL decoder, chosen to remove memory-safety risks in a browser attack surface.
  • The authors say fuzzing and AI review found no memory safety bugs in jxl-rs across its entire implementation history.
  • The post claims JPEG XL offers 30-50% better compression than JPEG, plus lossless compression, built-in HDR and lossless JPEG transcoding.
  • Chrome recommends trying both AVIF and JPEG XL, and says the decision to ship followed consistent developer requests, visible in the Interop Process.

Why it matters

JPEG XL support in Chrome changes what web developers can reasonably serve to Chrome users. The post frames the decision as a response to years of developer requests, seen in the Interop Process, where JPEG XL was a popular proposal in 2026 and several years before. It is also a notable data point for Rust in browsers: the authors argue that a Rust decoder, with unsafe code restricted to a few highly vetted places, can remove a whole class of memory bugs from a high-risk component without a significant speed penalty. Getting there needed Rust's target_feature_11 feature to be stabilized, so safe SIMD was a prerequisite.

Who it affects

Web developers and content creators who produce or serve images, and platform owners whose pipelines could now emit .jxl files and animations to Chrome users. Photographers and sites that care about high-fidelity or lossless photographic images are the group the authors single out as most likely to benefit. Chrome users are affected indirectly: the post presents the Rust decoder as a way to keep a common attack surface safer.

How to use it

The post encourages developers to start using .jxl images and animations in their pipelines from Chrome 155 onward, and to file bugs. Its practical advice on format choice is to try both AVIF and JPEG XL and compare, with JPEG XL expected to shine for high-fidelity or lossless compression, especially of photos, or where fine-grained progressive decoding matters. The post does not say whether JPEG XL decoding is enabled by default or behind a flag, and gives no release date for Chrome 155. Only decoding is covered; no encoder support in Chrome is mentioned.

How solid is it

This is a first-party announcement from the Chrome team on the Chrome developers blog, so the shipping commitment itself is well sourced. The technical claims are the team's own: that jxl-rs is approximately as fast as the best non-memory-safe alternative (stated as a design goal, with a performance dashboard linked rather than benchmark numbers) and that no memory safety bugs were found in its whole history via fuzzing and AI review. The 30-50% compression gain over JPEG comes with no baseline, image set or quality metric.

Risks and caveats

The 30-50% figure is a promotional claim without stated test conditions, so real savings will vary and are worth measuring on your own images. A clean fuzzing and AI-review record is evidence, not proof, that no memory bugs remain, and the post itself calls sandboxing a secondary layer of defense. The post says nothing about Firefox, Safari or other browsers' support, so sites will still need fallbacks or format negotiation for other clients. The post names no byline author, and it is a vendor's account of its own decision.

“In general, we recommend trying both AVIF and JPEG XL to get the best results.”

— Chrome team, Chrome developers blog