Shipping JPEG XL in Chrome
Chrome is officially shipping JPEG XL support in version 155, powered by a new Rust-based decoder for enhanced security and performance. This move marks a significant U-turn for Google, delighting web developers who had championed the advanced image format after its controversial removal, reigniting discussions about browser politics and the future of web image standards.
The Lowdown
Chrome is officially re-introducing decoding support for the JPEG XL (.jxl) image format starting with Chrome 155. This next-generation format aims to address modern web and photography needs, boasting 30-50% better compression than JPEG, lossless capabilities, built-in HDR, and lossless JPEG transcoding. The article highlights the technical journey and rationale behind this decision.
- Security First with Rust: Recognizing image decoders as critical attack surfaces, Chrome integrated
jxl-rs, a pure Rust implementation. This move aims to eliminate memory safety vulnerabilities common in C++ decoders, aligning with Chrome's "rule of two" security principle. - Performance Without Compromise: The Rust decoder was engineered for speed, leveraging SIMD hardware through Rust's
target_feature_11and a SIMD abstraction layer inspired by Google's Highway library. Extensive optimizations and verification (fuzzing, AI review) have ensured performance comparable to C++ while maintaining memory safety. - Developer-Driven Re-adoption: The decision to ship JPEG XL was a direct response to consistent feedback and requests from web developers, prominently voiced through channels like the Interop Project. Chrome also participated in Interop 2026 to ensure cross-browser compatibility.
- Call to Action: Developers, content creators, and platform owners are encouraged to adopt
.jxlimages and animations to contribute to a faster, richer, and safer web.
The re-introduction of JPEG XL in Chrome, backed by a robust and secure Rust implementation, signifies a major step forward for web imagery, promising enhanced performance and visual fidelity for users globally.
The Gossip
The Great Google Reversal: A JXL Comeback Story
The most dominant theme is the dramatic reversal of Google's previous decision to remove JPEG XL support from Chrome. Commenters recall the prior deprecation and removal, speculating on the reasons for the U-turn. Theories range from external pressure (other browsers adopting it, Adobe including it in PDF spec, Apple's iOS support), to internal engineering wins, to the availability of a secure Rust decoder (`jxl-rs`) mitigating earlier security concerns. Many express relief and excitement that JXL is finally getting its due.
Codec Conundrums: The Ongoing Image Format Wars
The discussion inevitably dives into the broader landscape of image formats. Many express frustration with the proliferation of formats (WebP, AVIF, HEIC, JXL) and the resulting compatibility issues across applications and operating systems (e.g., Telegram's WebP handling, Windows/macOS support lag). Commenters debate the merits of JPEG XL against AVIF (especially for lossless vs. lossy scenarios), and WebP, with many seeing JXL as a superior, "be-all-end-all" format due to its versatility and features like progressive rendering and lossless JPEG transcoding, potentially ending the need for multiple formats.
JXL's Technical Prowess & Practicalities
Users laud JPEG XL's technical advantages, including superior compression, true lossless capabilities, HDR support, and features like progressive rendering that could eliminate the need for separate thumbnails. The Rust implementation (`jxl-rs`) is highlighted as a key enabler for security and performance. However, practical concerns are also raised, such as the computational cost of encoding (especially for on-the-fly server-side compression), the current limited adoption on `caniuse.com`, and the lack of clarity on whether a `.jxl` file is lossy or lossless just from its extension.
The "Why Not a System-Wide Codec?" Debate
A recurring sentiment is the desire for a system-wide codec architecture, reminiscent of AmigaOS DataTypes or BeOS Translators, where installing a single library would enable support for new image formats across all applications. Commenters question why browsers need to bundle every decoder internally rather than relying on OS-level components, while others argue for browser independence for consistency, security, and control over the user experience. The difficulties of keeping system-wide codecs updated and secure are also noted.