After dropping JPEG XL support from Chrome in 2022 and claiming insufficient industry interest, Google has reversed course and added JXL decoder support to Chromium. The decision follows years of industry pressure, competing browser adoption, and the maturation of a memory-safe Rust-based decoder.
Google has officially reintroduced JPEG XL (JXL) support to Chromium, marking a stunning reversal of its 2022 decision to abandon the format. A recent commit enables the JXL decoder by default, meaning future releases of Google Chrome and other Chromium-based browsers will natively process and display JXL images.
The Format That Refused to Die
JPEG XL emerged from a 2017 ISO/IEC call for proposals, combining Cloudinary's FLIF format with Google's own PIK technology. It was standardized as ISO/IEC 18181 in 2021 with a 2024 revision. The format promised significant advantages over legacy JPEG and PNG: lossless recompression of existing JPEGs at 20% smaller file sizes, progressive decoding that prioritizes salient image elements, and superior compression compared to AVIF, MozJPEG, and WebP.
The format gained rapid traction. Chrome and Firefox implemented experimental support in 2021. But in 2022, Google Chrome engineers abruptly removed JXL code, citing "not enough interest from the entire ecosystem" and claiming the format "does not bring sufficient incremental benefits." They also argued removal would reduce maintenance burden.
Industry Pushback
Google's justification drew immediate criticism. The Chromium bug tracker accumulated over 500 comments disputing the claim. Intel's Roland Wooster argued JXL was the only format supporting HDR still images with 16-bit per color channel and wide color gamuts like ProPhoto used by DSLR photographers. Adobe, Cloudinary, Facebook, The Guardian, and Shopify all expressed support.
Cloudinary's Jon Sneyers, a JPEG XL spec editor, called the maintenance argument "absurd," noting it required little more than occasionally updating version numbers in build scripts.
The Ecosystem Moved Forward
While Google stalled, competitors advanced:
- Apple: Implemented JXL support in WebKit for Safari 17 (June 2023)
- Microsoft: Added native support in Windows 11 version 24H2 (March 2025)
- Mozilla: Committed to adoption once a Rust-based decoder became available, citing safety concerns about the 100K+ lines of multithreaded C++ in libjxl
- PDF Association: Added JXL support to the PDF spec (November 2025)
The Rust Factor
The turning point appears to be the maturation of jxl-rs, a memory-safe Rust implementation of the JPEG XL decoder. Mozilla had explicitly stated this as a prerequisite for Firefox adoption. Google's November 2025 Blink mailing list announcement signaled intent to integrate this Rust-based decoder, and the January 2026 Chromium commit makes it official.
Why This Matters for Builders
For homelab enthusiasts and web developers, this reversal validates years of advocacy. JPEG XL offers concrete technical benefits:
- Bandwidth savings: 20% reduction when recompressing existing JPEG archives
- Progressive rendering: Better perceived performance on slow connections
- HDR support: Future-proofing for high dynamic range content
- Lossless archival: Superior to PNG for preservation
- Universal compatibility: Works across all major browsers (Safari already supports it, Firefox pending Rust decoder)
The format's journey from standardization to browser support, through abandonment and back, illustrates how technical merit alone isn't enough. Industry coordination, memory safety concerns, and competitive pressure all played roles. For anyone measuring bandwidth costs or optimizing image delivery pipelines, JXL just became a practical choice rather than a theoretical one.
Chromium-based browsers will include JXL support in upcoming releases. The ecosystem that Google claimed didn't exist has proven otherwise.
Comments
Please log in or register to join the discussion