⏱️ Reading time: 8 min
Chrome now reads .jxl files without plugins: version 155 of the browser natively decodes JPEG XL in Chrome, with a decoder written from scratch in Rust. Google announced it on October 6, 2026 on the Chrome for Developers blog, after years of constant requests from developers within the web interoperability process.
📑 En este artículo
This is more than just another format added to the compatibility list. It’s the first time Chrome ships a complete image decoder built in a memory-safe language, after years of vulnerabilities in decoders written in C++.
TL;DR
- Chrome 155 natively decodes JPEG XL (.jxl) with a decoder rewritten in Rust.
- JPEG XL compresses 30%-50% better than JPEG, with a lossless mode and reversible transcoding.
- jxl-rs, the Rust decoder, avoids the out-of-bounds reads and use-after-free bugs of the previous C++ implementation.
- Rust stabilized target_feature_11 to use SIMD without unsafe code and without losing performance compared to libjxl.
- Google pushed Interop 2026 to lock in JPEG XL test coverage across all browsers.
What JPEG XL in Chrome Is
JPEG XL is a next-generation image format designed by the JPEG committee for photography and web content. It compresses between 30% and 50% better than JPEG, supports lossless compression, native HDR, and reversible transcoding of existing JPEG files without losing quality.
The format is driven by a small group of engineers, including Luca Versari, Moritz Firsching, and Philip Jägenstedt, authors of the Chrome announcement. Their stated goal is to cover both high-fidelity photography and the images that today live as JPEGs on billions of sites.
What Happened
Starting with Chrome 155, any site can display JPEG XL in Chrome natively, without extensions or experimental flags. Google clarifies that, for now, support covers only decoding: Chrome still doesn’t include an encoder to generate .jxl files from the browser.
The team recommends developers test both AVIF and JPEG XL before choosing a production format. According to the announcement, JPEG XL performs better in high-fidelity compression, lossless images, and cases where detailed progressive decoding is useful, while AVIF remains a solid alternative for general lossy compression.
The post details three areas of work: the decoder rewrite in Rust for security, the performance work to match the C++ reference implementation, and Chrome’s participation in the web interoperability process that ultimately pushed the launch forward.
Context and History
JPEG XL isn’t new: the JPEG committee standardized it as JPEG’s successor, intending to replace both everyday photography and the professional workflows that still rely on TIFF or PNG to avoid quality loss. Chrome had tested the format before, behind an experimental flag, and removed it in 2022 without giving it immediate continuity, which sparked a strong reaction among developers and photographers who had already adopted it.
That removal turned the format into one of the most discussed proposals within Project Interop, the process where browsers agree on which features to prioritize so the web works the same everywhere. Chrome’s announcement confirms it was a popular proposal in 2026 and in previous years within that process, something that ended up outweighing the Chrome team’s initial resistance.
The result is an unusual history for a web standard: it went from having experimental support, to being removed, to returning four years later with a completely new implementation and a security argument that didn’t exist in the first round.
Technical Details
Image decoders are one of the most exploited attack surfaces in any browser: they process complex binary data that arrives straight from the network and run inside the process that renders the page. Historically, C++ decoders have suffered from out-of-bounds reads, heap overflows, and use-after-free errors, the kind of bug that ends up as an exploitable vulnerability.
Chrome already applies process isolation as a first line of defense, under what the team calls the rule of two: a component that processes untrusted data, runs in a sandbox, and is written in a memory-unsafe language is considered high-risk by design. jxl-rs directly eliminates the third condition, because it’s a complete reimplementation of the decoder written in Rust, without relying on the sandbox as the only barrier.
The problem with rewriting in Rust is that image codec performance depends on heavy use of hardware SIMD instructions, something that traditionally requires unsafe code. To avoid this, the team stabilized the language feature target_feature_11, which allows using SIMD instructions without unsafe blocks. On top of that, they built jxl_simd, an abstraction layer inspired by Highway, the same C++ library originally designed for libjxl, the format’s reference implementation.
With those two pieces, jxl-rs reuses libjxl’s performance optimizations, including a pipeline that minimizes data copies between image regions during processing. Google says it verified the implementation with fuzzing and AI-assisted code review, without finding any memory-safety bugs in the project’s entire history.
| Format | Lossy compression | Lossless mode | Native HDR | Transcodes existing JPEG |
|---|---|---|---|---|
| JPEG | Comparison baseline | No | No | – |
| AVIF | Better than JPEG, already supported in Chrome | Yes, but rarely used | Yes (PQ/HLG) | No |
| JPEG XL | 30%-50% better than JPEG | Yes | Yes | Yes, lossless |
flowchart TD
A["Server sends .jxl image"] --> B["Chrome network process"]
B --> C["Renderer process"]
C --> D["jxl-rs: Rust decoder"]
D --> E["RGB or HDR pixels"]
E --> F["Screen compositing"]
subgraph Isolation
C
D
endThe combination is unusual: normally gaining memory safety means sacrificing performance, or keeping performance at the cost of unsafe code scattered throughout the project. jxl-rs bets that a well-designed abstraction layer avoids that dilemma.
Impact and Analysis
The jxl-rs case adds to a growing list of critical Chrome components rewritten in Rust, part of a broader strategy to reduce the share of memory-safety vulnerabilities that has historically dominated the browser’s security reports. A new, memory-safe image decoder comparable in speed to the original C++ version is exactly the kind of component where that language switch pays off most, because it runs in every tab, on any image from any site.
For developers, the arrival of JPEG XL in Chrome 155 reopens a decision that had been on hold for years: which image format to use in production. The format competes directly with AVIF in lossy compression, but adds two capabilities AVIF doesn’t offer: reversible transcoding of existing JPEG files and a lossless mode designed for professional photography.
💭 Key point: lossless transcoding lets you convert an old JPEG to .jxl and recover the original JPEG byte for byte if needed, something no other modern image format offers today.
The real limitation is fragmentation between browsers. Support for the .jxl codec in Firefox and Safari remains partial or nonexistent depending on the browser, so a site that serves .jxl directly without a fallback will leave some visitors without an image. The practical recommendation, both from Google and from standard industry practice, is to serve JPEG XL inside a picture element with a fallback source in AVIF or JPEG.
What’s Next
Chrome took part in the Interop 2026 investigation into JPEG XL specifically to ensure test coverage exists for all of the format’s features across browsers, and that those tests pass in Chrome. That suggests the medium-term goal is to push other engines to add equivalent support, not just to have Chrome decode the format on its own.
The other half of the work is still missing: a native encoder in the browser or in the most common build tools. In the meantime, generating .jxl files still depends on command-line tools based on libjxl, which limits adoption to teams that already automate their image pipeline.
Try it yourself: update to Chrome 155 (or a more recent canary build) and open a .jxl file directly in the address bar to see the Rust decoder working today.
Frequently Asked Questions
What is JPEG XL in Chrome 155?
It’s native decoding support for the .jxl image format that Chrome adds starting with version 155, using a decoder rewritten in Rust called jxl-rs instead of the historical C++ implementation.
Does Chrome 155 also let you create .jxl files?
No. Google’s announcement covers only decoding: Chrome can display .jxl images that already exist, but it doesn’t include a native encoder to generate them from the browser.
Does JPEG XL replace AVIF or WebP?
It doesn’t replace them, it competes with them in different use cases. Google recommends testing both AVIF and JPEG XL: AVIF tends to perform better in general lossy compression, while JPEG XL stands out in high fidelity, lossless mode, and reversible JPEG transcoding.
Why did Google rewrite the decoder in Rust instead of using libjxl directly?
Because image decoders process untrusted binary data inside the process that renders the page, and they’re one of the most exploited targets in browsers. Rust eliminates memory-safety bugs at the source, instead of merely mitigating them after they occur, which is all the sandbox can do.
Does JPEG XL work the same way in Firefox and Safari?
Not yet. Support outside Chrome is partial or nonexistent depending on the browser, so it’s best to serve JPEG XL with a fallback format using the picture element until coverage evens out.
References
- Chrome for Developers: official announcement of JPEG XL support in Chrome 155 and details of the jxl-rs decoder.
- GitHub: libjxl: reference C++ implementation of the JPEG XL format.
- JPEG.org: official JPEG committee page about the JPEG XL standard.
- Wikipedia: JPEG XL: history of the format, including its experimental removal from Chrome in 2022.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Featured image: Foto de Pankaj Patel en Unsplash
Did it work for you? Got a different error? Say so below: questions get answered and help the next reader.
Leave a comment
0 Comments