Published: October 6, 2026
\nWe're excited to announce that Chrome is shipping decoding support for the JPEG\nXL (.jxl) image format starting from Chrome 155. JPEG XL is a next-generation\nimage format designed to meet the needs of modern web developers and\nphotographers. It offers 30-50% better compression than JPEG, lossless\ncompression, built-in HDR support, lossless JPEG transcoding, and more.
In general, we recommend trying both AVIF and JPEG XL to get the best results. We expect that JPEG XL is most helpful for high-fidelity or lossless compression, especially of photographic images or in cases in which fine-grained progressive decoding is preferred.
\nIn this post, we share why we brought JPEG XL to Chrome, how we used Rust to ensure memory safety first, the extensive performance work that makes it fast, and what the journey tells us about developer feedback and the web standards ecosystem.
\njxl-rs)Image decoders are one of the most critical and targeted attack surfaces in any modern web browser. They process complex, untrusted binary structures directly from the network and run inside the 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.
\nOur security model relies on sandboxing and defense-in-depth, guided by the\nrule of\ntwo.\nHowever, sandboxing is a secondary layer of defense. To eliminate these security\nrisks at the source, we have integrated jxl-rs, a pure Rust implementation of\nthe JPEG XL decoder.
Memory safety is crucial, but a memory-safe decoder that is approximately as fast as the best non-memory-safe alternative is a much more obvious choice than a choice with a significant performance compromise.
\nA fundamental part of the performance of modern codecs is making full use of the\nSIMD hardware available on modern devices. To do so safely,\ntarget_feature_11 Rust\nfeature had to be stabilized, which allowed the use of SIMD instructions without\nrequiring unsafe code.
The next step was to build a SIMD abstraction layer (jxl_simd), inspired by\nthe C++ Highway library (itself originally\ndeveloped for libjxl, the C++ reference implementation of JPEG XL). Together,\nthose developments allowed writing a multi-platform library that doesn't\ncompromise on SIMD performance optimizations, while restricting unsafe\noperations to a small number of highly-vetted locations.
Performance optimizations in jxl-rs build on those in libjxl. This includes\na generic processing pipeline for steps crossing region borders, while\nminimizing data copies to maximize hardware performance. We've been tracking the\nperformance of the Rust reimplementation across different hardware platforms on\nthe jxl-rs performance dashboard.
We verified the jxl-rs implementation with various state-of-the-art\ntechniques, including fuzzing and AI review of the code, and have not found any\nmemory safety bugs throughout the entire implementation history, providing yet\nanother validation of the huge improvements that Rust brings to memory safety.
The Chrome team considers web developer feedback from a wide range of channels,\nsuch as bugs, surveys, the Developer Signals\nProject,\nand the Interop Project. Our\ndecision to ship JPEG XL was based on consistent feedback and requests from web\ndevelopers, most visible in the Interop Process, where it was a popular\nproposal in 2026 and\nseveral years prior.
\nTo ensure the format is interoperable across browsers, we have participated in\nthe Interop 2026 JPEG XL\nInvestigation to ensure\nthere is test coverage for all of JPEG XL's features in browsers, and that those\ntests pass in Chrome.
\nWith JPEG XL officially landing in Chrome, the web becomes faster, richer, and\nsafer. We encourage developers, content creators, and platform owners to start\nusing .jxl images and animations in their pipelines.
Try it out, file bugs,\nand help us continue building a faster and safer web for everyone.
\nWe'd like to thank all the people who contributed to jxl-rs or its integration\nin Chrome, and especially Helmut Januschka for the substantial contributions\nboth to the Chrome integration and jxl-rs, and Martin Bruse, Zoltan Szabadka,\nSami Boukortt and Wonwoo Choi for their substantial contributions to jxl-rs\nitself.