Chrome 155 ships JPEG XL with a Rust-based decoder for safety and speed

Starting with Chrome 155, the browser now supports decoding the JPEG XL image format. This update arrives after years of developer requests and extensive engineering work to ensure the new codec is both secure and fast. The move marks a significant shift in how Chrome handles complex media parsing, prioritizing memory safety without sacrificing rendering speed.

What happened

The Chrome team has officially integrated decoding support for JPEG XL, identified by the .jxl file extension. This next-generation format is designed to serve modern web needs, offering compression that is 30-50% more efficient than standard JPEG. Beyond simple size reduction, the format supports lossless compression, built-in High Dynamic Range (HDR) capabilities, and lossless transcoding of existing JPEG files. While AVIF remains a strong competitor, the team recommends testing both formats to determine which yields the best results for specific use cases. JPEG XL is particularly suited for high-fidelity photographic images and scenarios requiring fine-grained progressive decoding.

This release is not just about adding a new file type; it represents a fundamental change in the browser’s security architecture for media handling. Image decoders are a primary target for attackers because they process untrusted binary data directly from the network within the renderer process. Historically, these components were written in C++, a language prone to memory safety vulnerabilities like heap overflows and use-after-free errors. To address this, Chrome replaced the traditional C++ approach with jxl-rs, a pure Rust implementation of the JPEG XL decoder. This decision eliminates entire classes of security risks at the source code level rather than relying solely on sandboxing as a secondary defense.

How it works

Achieving high performance in a memory-safe language like Rust required specific technical advancements. Modern codecs rely heavily on SIMD (Single Instruction, Multiple Data) hardware instructions to process pixels quickly. Previously, using these instructions in Rust often required unsafe code blocks, which could reintroduce memory safety risks. The Chrome team leveraged the stabilized target_feature_11 feature in Rust, which allows the use of SIMD instructions without marking the code as unsafe. They also built a SIMD abstraction layer called jxl_simd, inspired by the C++ Highway library used in the reference libjxl implementation. This architecture restricts unsafe operations to a small, highly vetted area while allowing the rest of the decoder to remain memory-safe.

The performance of jxl-rs builds upon optimizations found in the original C++ reference implementation. It uses a generic processing pipeline that minimizes data copies when handling region borders, maximizing hardware efficiency. The team verified the robustness of this new decoder through rigorous fuzzing and AI-assisted code reviews. Throughout the entire development history of jxl-rs, no memory safety bugs were found, validating the effectiveness of using Rust for critical infrastructure components. Performance metrics are continuously tracked on a dedicated dashboard across various hardware platforms to ensure the Rust version matches or exceeds the speed of non-memory-safe alternatives.

Key details

• Chrome 155 introduces native decoding support for the JPEG XL (.jxl) image format.
• JPEG XL provides 30-50% better compression compared to standard JPEG files.
• The decoder is implemented in Rust (jxl-rs) to eliminate memory safety vulnerabilities like buffer overflows.
• Performance is maintained using the target_feature_11 Rust feature and a custom jxl_simd abstraction layer.
• The decision to ship was driven by consistent developer feedback via the Interop Project and Developer Signals.
• No memory safety bugs were found in jxl-rs during its development, confirmed by fuzzing and AI code review.

Why it matters

For software engineers and technical leads, this update highlights a maturing ecosystem where memory safety is becoming a default requirement rather than an optional enhancement. By moving critical parsing logic to Rust, Chrome reduces the attack surface of the browser significantly. This sets a precedent for other browsers and software projects that handle untrusted input. It demonstrates that high-performance systems do not need to compromise on safety if the right tools and abstractions are available. For teams building web applications, this means a more stable and secure environment for delivering rich media content.

From a practical standpoint, developers now have a powerful new tool for optimizing web performance. The ability to serve images that are significantly smaller than JPEGs while maintaining higher fidelity can reduce bandwidth costs and improve load times. The support for lossless JPEG transcoding is particularly useful for legacy content migration, allowing sites to upgrade their image assets without re-encoding from scratch. As interoperability tests pass across browsers, adopting .jxl becomes a viable strategy for improving core web vitals and user experience.

What you can do

• Update your development environment to test with Chrome 155 or later to verify JPEG XL rendering.
• Convert key photographic assets to .jxl format and compare them against AVIF to find the optimal balance of size and quality.
• Implement responsive image strategies that include .jxl sources for browsers that support the format.
• Monitor the Interop 2026 JPEG XL Investigation results to track cross-browser compatibility progress.
• Provide feedback to the Chrome team by filing bugs if you encounter rendering issues or performance regressions.
• Review your current image pipeline to identify opportunities for lossless JPEG transcoding to JPEG XL.