Chrome's JPEG XL comeback gives web developers another image output to generate before it gives them one they can delete. The announcement had reached 158 points in the Hacker News discussion when MrKeyoor's feed captured it, a burst of community attention for a codec that Chrome once removed from an experimental flag. Starting with Chrome 155, the browser will decode .jxl images again, this time through a Rust implementation built to handle untrusted image data with less memory-safety risk.
Google's announcement says JPEG XL can compress images 30% to 50% better than JPEG and supports lossless compression, HDR, animation, progressive decoding and lossless transcoding of existing JPEG files. Those are Google's figures and capabilities, not a promise that every page will shrink by the same amount. The result depends on the source image, encoder settings and what you compare it with. Google itself tells developers to test both AVIF and JPEG XL.
That qualification matters. Chrome 155's decoding support makes JPEG XL a practical candidate for more web pipelines, but it does not make JPEG or AVIF obsolete on release day. A production rollout should begin as an extra source inside a <picture> element, backed by formats that older clients already understand.
The decoder changed the argument
Chrome has been here before. Its older platform-status entry records that Chromium had an experimental JPEG XL implementation behind a flag and later removed it. The new launch is therefore a return with a different implementation, not the first time the codebase has encountered the format.
The difference sits below the file extension. Chrome 155 uses jxl-rs, a JPEG XL decoder written mostly in safe Rust. Image decoders accept complex binary files from any server and run as part of the browser's rendering machinery. A malformed image can exercise parsing code before a person has chosen to interact with the page. Google names out-of-bounds reads, heap overflows and use-after-free bugs among the failure classes that have affected decoders written in memory-unsafe languages.
Mozilla had identified the same problem well before Chrome's new announcement. In a September 2024 standards-position change, Mozilla said its concern was the attack surface of a reference decoder containing more than 100,000 lines of multithreaded C++. The browser maker said it would consider shipping JPEG XL if a Rust decoder proved safe, fast, compact and compatible enough for production. The current jxl-rs documentation says the decoder is now used by both Chrome/Chromium and Firefox.
Rust alone does not make a decoder fast. Image codecs depend heavily on SIMD instructions, which let a processor apply one operation across several values at once. Chrome says stabilization of Rust's target_feature_11 work allowed the project to use those instructions without placing the whole path inside unsafe blocks. The team then built a jxl_simd abstraction inspired by Highway, the C++ SIMD library used by the reference JPEG XL implementation.
Some unsafe code remains. The jxl-rs README says it is used where performance calls for it, including parts of SIMD, and requires detailed safety comments plus review by someone other than the author who knows unsafe Rust. That is a bounded claim about the code-review policy. It should not be read as a guarantee that the decoder has no defects. Google reports that fuzzing and AI-assisted review have found no memory-safety bugs in the implementation's history, but the decoder will now face a far larger and messier input set in browsers.
A format win still means a pipeline cost
Chrome's format description says JPEG XL can store lossy or lossless images, animation, wide-gamut color and HDR. The format also supports alpha transparency and high bit depth. Its lossless JPEG transcoding offers a migration path that preserves the original JPEG image data instead of introducing another lossy encode. For photo archives and sites serving large, high-fidelity images, those features can reduce the need to keep separate formats for separate jobs.
The web-delivery decision is narrower. Google expects JPEG XL to be most useful for high-fidelity or lossless photographs and for images where fine-grained progressive decoding is wanted. It recommends comparing the output with AVIF rather than declaring one default winner. AVIF may produce the better file for one source, while JPEG XL may win on another or offer the behavior a publisher needs. Encoding time, decoding speed and visual artifacts belong in that test alongside byte size.
The HTML Standard's fallback mechanism makes a cautious rollout straightforward. For now, the safest markup is deliberately boring:
<picture>
<source srcset="/images/hero.jxl" type="image/jxl">
<source srcset="/images/hero.avif" type="image/avif">
<img src="/images/hero.jpg" alt="A developer testing image formats">
</picture>
The browser checks the sources in order and uses one it supports, following the HTML Standard's picture-selection rules. The JPEG remains the final fallback. This approach costs storage and build time because the image service must create and cache several derivatives. It also lets a team add JPEG XL without making a support guess for every browser, embedded webview, crawler or long-lived device that may request the page.
Serving .jxl through content negotiation alone needs more care. A CDN cache must vary correctly on the signal used to choose the format, and a mistaken capability check can return an undecodable response. The explicit type path keeps the choice in the browser and leaves the original <img> available. Teams should still verify that their CDN sends image/jxl, that optimization middleware does not rewrite the file, and that image dimensions and caching headers survive the new branch.
Browser support is finally converging
Apple added JPEG XL in Safari 17. Mozilla's 2024 position tied Firefox adoption to the Rust decoder, and the decoder project now lists Firefox as a user. Chrome's arrival fills the most visible hole in the browser set, though exact coverage will still depend on browser version, operating system and embedded runtime.
The standards work has also moved beyond vendor statements. JPEG XL is standardized as ISO/IEC 18181. A proposal to make it part of the Interop 2026 testing effort accumulated 788 GitHub reactions and 53 comments before closing. The associated investigation focuses on shared web-platform tests, giving browser teams the same bitstreams and expected behavior instead of leaving each implementation to define its own passing result.
That testing is more important than the label on a compatibility table. JPEG XL includes animation, color management, progressive rendering and several container features. Two browsers can both claim support while disagreeing on an edge case that changes pixels, timing or metadata. Chrome says its goal in the Interop work is test coverage for the format's features and passing results in Chrome. It does not claim that every implementation is already identical.
Community interest is easy to understand. The Hacker News discussion grew quickly on October 7, but the thread is a demand signal rather than proof of compression or security claims. The useful evidence comes from the shipping notice, decoder code, browser positions and shared tests. Together they explain why a format that lost its Chromium flag now has a route back into ordinary web delivery.
What teams should measure first
A sensible trial follows Google's advice to compare AVIF and JPEG XL on a small group of photographic assets where transfer size matters and visual review is possible. Encode the same originals at comparable perceived quality, then record output bytes, encode time and decode behavior on the devices that matter to the service. Keep the JPEG fallback in place and watch real requests before expanding the set.
The release to watch is Chrome 155 itself, followed by its downstream arrival in Chromium-based browsers and webviews. Decoder crashes, color mismatches and progressive-rendering differences found under that load will say more than a launch-day compression chart. If those reports stay quiet and Interop tests converge, teams can widen JPEG XL use one image class at a time. The day to remove a fallback comes later, when traffic data shows that the clients still receiving it have become negligible.