Quick Answer: Google is officially shipping decoding support for JPEG XL in Chrome starting with version 155. This next-generation image format offers 30-50% better compression than legacy JPEG, built-in HDR support, and progressive decoding. Chrome ensures memory safety by using a pure Rust-based decoder implementation called
jxl-rs.
Web performance advocates spent years mourning the removal of JPEG XL from Chromium. In a dramatic shift, Google reversed course, officially shipping decoding support for JPEG XL in Chrome starting with version 155. This decision marks a major milestone for web standards, proving that developer consensus can reshape browser roadmaps. If you manage high-traffic web properties or photographic portfolios, this update fundamentally changes how you deliver visual media.
The Dramatic U-Turn: Why Google Brought Back JPEG XL in Chrome
In late 2022, Google removed the experimental JPEG XL flag in Chrome 110. The justification at the time was a lack of ecosystem interest and insufficient performance benefits over existing formats. This decision triggered widespread backlash from the web development, photography, and open-source communities. The Interop Project, specifically the Interop 2026 JPEG XL Investigation, became the battleground where developers demanded its return.
According to the Chrome Developer Blog, the decision to ship was heavily influenced by consistent feedback through the Developer Signals Project. Web developers made it clear that existing alternatives did not fully satisfy the requirements of high-fidelity photography and progressive rendering.
To ensure the format is interoperable across browsers, Google participated in extensive cross-browser testing. This means you can expect consistent rendering behaviors across different engines. If you have been holding off on adopting next-generation image formats due to browser fragmentation, the landscape has officially shifted.
That said, there's a catch that kept security engineers awake at night before this release could happen.
The Security Imperative: Rewriting the Decoder in Rust
Image decoders are notorious attack vectors. They parse complex, untrusted binary streams directly from the network and run inside the highly sensitive renderer process. Historically, decoders written in memory-unsafe languages like C++ have been prone to vulnerabilities such as out-of-bounds reads, heap overflows, and use-after-free bugs.
To eliminate these security risks at the source, the Chrome team integrated the jxl-rs Rust decoder, a pure Rust implementation of the JPEG XL decoder. This decision aligns with the "Rule of Two" security model: you can write code in an unsafe language (like C++) or run it unsandboxed, but never both. By using Rust, they eliminated memory safety bugs at the compile level without relying solely on sandboxing.
// The jxl-rs decoder ensures that memory safety is guaranteed
// at compile time, eliminating common C++ parser exploits.
When evaluating third-party media libraries for your own backend, prioritize memory-safe implementations over legacy C libraries. The Chrome team verified the jxl-rs implementation using state-of-the-art fuzzing and AI-assisted code reviews, finding zero memory safety bugs throughout its development history.
But memory safety often comes with a performance tax. Here's how the team bypassed that bottleneck.
Performance Without Compromise: SIMD and Hardware Acceleration
To make jxl-rs competitive with the C++ reference implementation (libjxl), the developers had to utilize Single Instruction, Multiple Data (SIMD) architectures. This required stabilizing the target_feature_11 Rust feature, allowing safe SIMD compilation without resorting to unsafe blocks.
They built jxl_simd, a port of the C++ Highway library, ensuring multi-platform hardware acceleration. Performance dashboards show that the Rust decoder achieves parity with optimized C++ code while maintaining absolute memory safety.
| Metric | Legacy JPEG | AVIF | JPEG XL |
|---|---|---|---|
| Compression Efficiency | Baseline | 30-50% better than JPEG | 30-50% better than JPEG |
| Lossless Transcoding | No | No | Yes (reconstructs original JPEG) |
| Progressive Rendering | Basic (Sequential) | No | Yes (Ultra-fine-grained) |
| HDR Support | Limited / Hacky | Yes | Yes (Native) |
| Memory Safety (Chrome) | C++ (Sandboxed) | C++ (Sandboxed) | Rust (jxl-rs) |
Ensure your server-side image optimization tools are compiled with target-specific CPU extensions (like AVX2 or NEON) to maximize throughput. This performance makes one specific, overlooked feature of the format incredibly practical.
This next part trips people up every time, but understanding it will save you terabytes of storage.
Lossless JPEG Transcoding: The Killer Feature Most Devs Miss
Most developers assume migrating to a new image format requires re-encoding from source files, which introduces generational loss. JPEG XL solves this with lossless JPEG transcoding. You can take an existing legacy JPEG, transcode it to JXL, and reduce the file size by roughly 20% without losing a single bit of original data.
Even better, this process is fully reversible. You can reconstruct the original legacy JPEG byte-for-byte if a legacy client requires it. This eliminates the need to store duplicate copies of your asset library.
[Original JPEG] ---> (Lossless Transcode) ---> [JPEG XL (20% smaller)] ---> (Revert) ---> [Original JPEG (Byte-for-Byte)]
Implement a dynamic edge worker that transcodes legacy JPEGs to JXL on the fly for supporting browsers, saving storage and egress costs simultaneously. This brings up the obvious question: how does this format stack up against the current darling of web images?
Here's where most guides go wrong by declaring a single winner.
AVIF vs JPEG XL: When to Use Which Format
A common mistake is treating all next-gen formats as interchangeable. AVIF vs JPEG XL is not a winner-take-all battle; they serve different use cases. AVIF is excellent for heavily compressed, low-bandwidth web assets like UI thumbnails. However, AVIF struggles with high-fidelity photography, often smoothing out fine textures like grass, skin, or fabric.
JPEG XL shines where AVIF fails. It preserves high-frequency details, supports ultra-high resolutions, and offers superior progressive decoding. Progressive decoding means the image renders in usable quality almost instantly, refining as more bytes arrive. AVIF, being based on video codecs (AV1), lacks this fine-grained progressive rendering, often loading in chunks or blocks.
Use AVIF for small, highly compressed interface elements, but default to JPEG XL for hero images, photography portfolios, and HDR content. This hybrid approach ensures the fastest possible load times without sacrificing visual quality.
Most people stop here—don't. Let's look at how to implement this practically.
Frequently Asked Questions
Why did Chrome deprecate JPEG XL?
Google deprecated the experimental JPEG XL flag in Chrome 110 citing a lack of ecosystem interest and insufficient performance benefits. However, strong developer feedback, the Interop Project, and the development of the memory-safe jxl-rs decoder led to its official return in Chrome 155.
How to use JPEG XL on the web?
To serve JPEG XL images while maintaining fallback support for older browsers, use the HTML <picture> element. This allows you to define the .jxl source first, falling back to AVIF or legacy JPEG if the browser does not support JPEG XL in Chrome yet.
<picture>
<source srcset="image.jxl" type="image/jxl">
<source srcset="image.avif" type="image/avif">
<img src="image.jpg" alt="High-fidelity photography example">
</picture>
Does JPEG XL support HDR?
Yes, JPEG XL has native, built-in support for High Dynamic Range (HDR) and wide color gamuts (WCG). Unlike legacy formats that require custom color profiles or hacky implementations, JPEG XL handles HDR metadata efficiently, making it the ideal format for modern displays.
Summary and Next Steps
The arrival of JPEG XL in Chrome represents a massive win for the web developer community and open standards. By combining the compression efficiency of modern codecs with the safety of a Rust-based decoder, Chrome has set a new standard for media delivery. Try deploying a few .jxl assets on your staging environment this week and note the rendering speed improvements. For more details on modern media pipelines, read our breakdown of AVIF vs JPEG XL or explore our guide on modern web performance standards next.