Introducing JPEG XL Support in Google Chrome

Authors: Luca Versari | Moritz Firsching | Philip Jägenstedt

Published: October 6, 2026

The Big News: Starting with Chrome 155, we are officially shipping decoding capabilities for the .jxl (JPEG XL) image format.

JPEG XL represents the next evolution in image formatting, specifically tailored to meet the rigorous demands of professional photographers and modern web developers.

Why JPEG XL?

This format isn't just a minor update; it's a comprehensive toolset for high-quality imagery. While we suggest utilizing both AVIF and JPEG XL to optimize your web assets, JPEG XL shines in specific scenarios:

• High-Fidelity Requirements: Ideal for lossless compression.
• Photography: Superior handling of photographic detail.
• Loading Experience: Preferred when fine-grained progressive decoding is necessary.

Comparison: Standard JPEG vs. JPEG XL

---

Prioritizing Security: The Shift to Rust

Image decoders are high-risk components because they parse untrusted binary data from the internet within the renderer process. In the past, decoders written in C++ were often plagued by:

• Heap overflows
• Use-after-free bugs
• Out-of-bounds reads

To mitigate these risks, we didn't just patch the old code; we reimplemented the decoder from the ground up using Rust via the jxl-rs library. By adhering to the "rule of two" for defense-in-depth and leveraging Rust's inherent memory safety, we've eliminated these vulnerabilities at the source.

The Decoding Pipeline

---

Engineering for Maximum Velocity

Safety is non-negotiable, but performance is paramount. To ensure jxl-rs matches the speed of non-memory-safe alternatives, we focused on SIMD (Single Instruction, Multiple Data) hardware acceleration.

1. Language Evolution: We waited for the stabilization of the target_feature_11 Rust feature, enabling SIMD instructions without needing unsafe blocks.
2. Abstraction Layer: We developed jxl_simd, a layer inspired by the C++ Highway library (used in the reference libjxl implementation).
3. Optimization: We implemented a generic processing pipeline to handle region borders while minimizing expensive data copies.

Verification Process:

• Fuzzing: Stress-testing the decoder with random data.
• AI Review: Utilizing machine learning to audit code logic.
• Monitoring: Tracking real-world metrics via the jxl-rs performance dashboard.

Result: Zero memory safety bugs have been discovered throughout the implementation history.

---

Community-Driven Development

The decision to integrate JPEG XL wasn't made in a vacuum. We rely on several feedback loops:

• The Developer Signals Project
• General bug reports and surveys
• The Interop Project

JPEG XL was a recurring request in the Interop process for several years. To ensure a seamless cross-browser experience, we participated in the Interop 2026 JPEG XL Investigation, verifying that all features are tested and functional within Chrome.

Implementation Guide

Ready to upgrade your assets? Follow these steps:

• Convert existing high-res assets to .jxl.
• Implement <picture> tags to provide fallbacks for older browsers.
• Test progressive loading speeds.
• Report any regressions via the bug tracker.

Example Implementation:

<picture>
  <source srcset="image.jxl" type="image/jxl">
  <source srcset="image.avif" type="image/avif">
  <img src="image.jpg" alt="Description of image">
</picture>

Final Thoughts & Credits

The arrival of JPEG XL makes the web faster, more visually rich, and fundamentally safer. We invite all creators and developers to begin integrating .jxl into their workflows.

Special Thanks: We owe a debt of gratitude to the contributors of jxl-rs, specifically:

• Helmut Januschka (Major contributions to both jxl-rs and Chrome integration)
• Martin Bruse, Zoltan Szabadka, Sami Boukortt, and Wonwoo Choi (Significant contributions to the jxl-rs library).

---

License Note: Content is under CC BY 4.0; code samples are under Apache 2.0. Java is a trademark of Oracle.