Chrome ships JPEG XL decoding with a Rust implementation
Chrome 155 will include native JPEG XL decoding powered by the jxl-rs crate written in Rust. The change lands after years of discussion inside the JPEG XL community and the Chromium project about how to bring the format to browsers without reintroducing the memory-safety issues that have plagued C and C++ image decoders. The announcement specifies that the decoder activates for JPEG XL files served with the image/jxl MIME type and for files that carry the .jxl extension when loaded directly.
Technical details of the integration
The jxl-rs decoder is a from-scratch implementation that avoids the original libjxl C++ codebase for the critical decoding path. Chromium engineers selected it because Rust’s ownership model eliminates entire classes of buffer overflows and use-after-free errors that have historically led to remote code execution in image libraries. The integration exposes the same Skia-backed rendering path used for other modern formats, so once the pixels are decoded they flow through the same color-management and HDR pipelines already present in Chrome.
Developers will notice several concrete capabilities. JPEG XL supports up to 32 bits per channel, wide color gamuts, and scene-referred HDR data. It also offers a lossless-recompression mode that can wrap an existing JPEG bitstream inside a smaller container without generational loss. Progressive decoding allows the browser to display a low-resolution preview while the remainder of the data arrives, a feature that was difficult to achieve reliably with earlier formats.
Why JPEG XL matters for photographic content
Current web image formats force trade-offs. JPEG remains ubiquitous but lacks HDR and produces visible artifacts at modest file sizes. WebP improved compression but still falls short on high-bit-depth and progressive delivery. AVIF delivers strong compression and HDR yet decoding can be slower on some hardware and the format lacks a lossless-JPEG path. JPEG XL was designed to improve on all three axes simultaneously while remaining royalty-free.
Because the format stores frequency coefficients in a way that permits partial decoding, a client can stop fetching once the visual quality meets a threshold. This property pairs well with responsive-image techniques already used in <picture> and srcset. Early internal tests inside Chrome showed that typical photographic pages could reduce transferred bytes by 15 to 25 percent compared with high-quality JPEG while preserving or improving visual fidelity.
Memory safety as a first-class requirement
Image decoding has long been a source of security incidents. The Chrome security team has tracked dozens of high-severity bugs in libjpeg, libpng, and libwebp over the past decade. By moving the JPEG XL decoder to Rust, the project reduces the attack surface that would otherwise be introduced by adding another complex format. The jxl-rs crate uses Rust’s type system to enforce that decoded buffers cannot exceed their allocated size and that all metadata parsing occurs before any pixel memory is touched.
Engineers involved in the effort noted that the Rust implementation also simplified fuzzing. The same corpus that previously triggered crashes in C++ decoders produced no memory errors when run against jxl-rs under sanitizers. This outcome aligns with broader industry movement toward memory-safe languages for untrusted input handling.
Developer-facing changes and testing
Starting in Chrome 155, authors can serve JPEG XL files to Chrome users without requiring JavaScript polyfills. Feature detection remains possible through the createImageBitmap API or by checking the decoded image’s color space and bit depth after loading. Developers targeting older Chrome versions or other browsers will continue to need fallback images or server-side content negotiation.
The implementation supports the full baseline feature set defined in the JPEG XL specification, including modular coding, VarDCT, and the lossless JPEG transcoding container. Advanced features such as animation and layered compositing are present but remain behind a runtime flag while additional testing completes.
Industry context and next steps
The JPEG XL standard was published by the JPEG committee in 2021. Browser support has lagged because implementers wanted both performance and safety guarantees. With the Rust decoder now shipping, other Chromium-based browsers are expected to pick up the same code in their next major releases. Firefox and Safari have not yet announced plans, though both have expressed interest in the format’s technical merits.
Content-delivery networks and image-optimization services are evaluating how to generate JPEG XL variants automatically. Because the format can losslessly wrap existing JPEGs, many sites can begin serving smaller files immediately without re-encoding their entire asset libraries. Over time, native JPEG XL assets will allow higher-fidelity HDR photography on the web without increasing bandwidth budgets.
Chrome 155 is scheduled to reach the stable channel in the coming weeks. Site owners who wish to experiment early can enable the feature via chrome://flags or by running the corresponding Dev or Canary build. The combination of a modern image format and a memory-safe decoder represents a rare alignment of capability and safety that web engineers have sought for years.
