- Chrome will decode JPEG XL images from version 155, using jxl-rs, a decoder written in Rust, a memory-safe language.
- Chrome says fuzzing and AI code review found no memory safety bugs in the decoder's history. That is a report, not proof.
- Leaders should ask which of their tools parse untrusted files, and in what language those parsers are written.
The safest new feature is the one built to resist its own bugs
Every new file format a browser supports is new code that reads data from strangers. The headline benefit of JPEG XL is smaller images. The more useful story is how Chrome built the reader.
The Chrome team announced on October 11 that Chrome will decode JPEG XL (.jxl) images starting with Chrome 155. It describes the format as offering 30-50% better compression than JPEG, plus lossless compression and built-in HDR support. Those are Chrome's claims about the format.
Why an image decoder is a security decision
A decoder takes raw bytes from the network and turns them into pixels. Those bytes can come from anyone. The decoder runs inside the browser's renderer process, the part that handles web content.
Chrome calls image decoders "one of the most critical and targeted attack surfaces" in a modern browser. Its post says decoders written in unsafe-memory languages such as C++ have a history of three kinds of flaw: reading past the end of a buffer, overflowing memory, and reusing memory after it was freed. In plain terms, the code can be tricked into reading or writing memory it should not touch.
Chrome relies on sandboxing, which walls off the renderer so a break-in stays contained. But the team calls sandboxing "a secondary layer of defense." Its aim was to remove the risk at the source.
How Chrome did it
Chrome integrated jxl-rs, a decoder for JPEG XL written entirely in Rust. Rust is built to rule out whole families of memory errors before the code runs.
The hard part was speed. Modern image codecs depend on SIMD, instructions that process many values in one step. Using them safely in Rust required the target_feature_11 language feature to be stabilized. That let developers use SIMD without writing unsafe code.
Next, the team wrote a thin layer called jxl_simd that sits between the decoder and the hardware instructions. It takes its design from Highway, a C++ library first created for libjxl, the C++ reference implementation. The result, Chrome says, is that the few operations Rust still treats as unsafe live in a handful of heavily reviewed spots. The decoder's performance work builds on libjxl.
Chrome's reasoning is a point worth borrowing. A memory-safe decoder that runs about as fast as the best unsafe alternative is an easy choice. One with a big performance penalty is a hard sell. The team says it did the engineering to keep safety from costing speed. The post points to a performance dashboard but publishes no comparison figures, so that claim is unmeasured here.
What the evidence does and does not show
Chrome says it checked jxl-rs with fuzzing, which feeds a program malformed input to provoke failures, and with AI review of the code. Its team states that it did "have not found any memory safety bugs throughout the entire implementation history."
That is the Chrome team's own account. Testing finds bugs; it cannot prove none exist. Still, it is a concrete result from a stated method, and it supports the case for choosing the language first.
What this means for your organisation
The lesson here is that the language and design of a component can lower risk before any attacker shows up. Patching after the fact is the weaker option. Your business does not ship a browser, but it does run software that opens files from outsiders: uploads, attachments, avatars, scanned documents.
Chrome also recommends testing both AVIF and JPEG XL to find the best result. It expects JPEG XL to help most with high-fidelity or lossless images, especially photos. The decision to adopt .jxl in your own image pipeline is a separate, practical one.
Questions to put to your teams:
1. Which of our systems parse files from outside parties, and what language are those parsers written in? 2. When we adopt a new format or library, who reviews its security record before launch? 3. Does our image pipeline need JPEG XL, AVIF or both, and have we measured the savings on our own images? 4. Do our vendors say how they handle memory safety, and can they show evidence?
Chrome's approach is one data point, not an industry trend. But it shows a clear pattern for any new feature that reads untrusted data: decide how the risk is removed before deciding how fast it ships.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: developer.chrome.com.
