By ByteBot
Google’s Chromium team announced last week it will restore JPEG XL image format support to Chrome, reversing a controversial October 2022 decision to remove the feature. Area Tech Lead Rick Byers said the team would “welcome contributions to a performant and memory-safe JPEG XL decoder in Chromium,” citing Safari’s existing support, Firefox’s updated position, and sustained developer demand evidenced by over 1,000 bug tracker upvotes.
This is a rare admission by Google that it was wrong—and it took three years, a standards body endorsement, and relentless developer pressure to make it happen.
Three Factors Forced Google’s Hand
Google didn’t reverse course out of goodwill. Three specific catalysts forced the decision. First, the PDF Association announced on November 10 that JPEG XL would be the “preferred solution” for HDR content in PDF specifications. PDF Association CTO Peter Wyatt praised the format’s wide color gamut, ultra-high resolution support, and up to 4,099 color channels with 32-bit depth—capabilities critical for professional documents.
Second, browser competition made Chrome the holdout. Safari already ships JPEG XL support, and Firefox updated its position to actively consider it. Google was isolated as the only major browser refusing to implement a format its competitors had validated.
Third, developer signals proved Google’s 2022 rationale—”not enough interest from the entire ecosystem”—was wrong. The Chromium bug tracker issue demanding JPEG XL support racked up over 1,000 upvotes, making it the second-most starred issue in Chromium history. Companies like Meta and Shopify publicly documented their interest. The PDF Association’s endorsement gave Google political cover to reverse without admitting defeat, but make no mistake: this is a victory for coordinated developer pressure.
“Not Enough Interest” Was Always Wrong
When Google removed JPEG XL support in October 2022, the company claimed there wasn’t enough ecosystem interest to justify continued experimentation. Developer outrage was immediate and sustained. The format’s bitstream was only frozen in late 2020, and it was standardized in 2021. Google pulled support barely a year after standardization—premature by any measure.
The 1,000+ bug tracker upvotes told a different story. Developers didn’t just disagree with Google’s decision; they documented specific use cases and organizational needs. Meta and Shopify, both heavy users of image delivery at scale, had already expressed interest. Google’s “not enough interest” claim looked less like data-driven analysis and more like an arbitrary decision that ignored clear signals from the community.
The 2025 reversal validates that skepticism. JPEG XL’s technical merits were always there—superior compression at high quality compared to WebP, faster decoding than AVIF, and a unique ability to losslessly transcode existing JPEGs with 20% file size reduction. Google delayed the format’s mainstream adoption by three years for no defensible reason.
Chrome Will Lead with Animation Support
Google’s new implementation comes with requirements that signal strategic shifts. The decoder must be written in Rust, not C++, reflecting Google’s broader push for memory safety across Chromium. More interesting, Chrome will be the first browser to support JPEG XL animations—a feature Safari hasn’t implemented despite supporting static images.
JPEG XL animation capabilities include frame blending modes (sum, replace, alpha-blend) and variable frame durations, making it superior to animated GIFs and WebP for cel-animation and stylized content. By leapfrogging Safari on animation support, Google is playing catch-up while trying to take the lead simultaneously—a position it created for itself by removing support in 2022.
The Rust requirement is notable beyond security. It aligns with Chromium’s memory-safety strategy and potentially excludes the original C++ library. Google is betting on jxl-rs, the Rust-based decoder, which means contributors will need Rust expertise. This isn’t just about adding a feature; it’s about reshaping the codebase’s technical foundations.
Cross-Browser JPEG XL Support by 2026
Google hasn’t committed to a specific timeline, stating Chrome will ship JPEG XL “once long-term maintenance and launch requirements are met.” Translation: no promises. However, the momentum is clear. Safari already supports the format, Firefox is actively reconsidering it, and Chrome’s reversal means cross-browser support is likely by 2026.
The PDF Association’s adoption as a standard format for PDFs legitimizes JPEG XL beyond browsers. Professional workflows—scientific documents, photography portfolios, technical manuals—will drive demand independent of web deployment. That standardization creates a floor for JPEG XL adoption that didn’t exist in 2022.
For web developers, the 20% lossless JPEG transcoding benefit is the killer feature. Billions of existing JPEGs across the web could shrink by a fifth with zero quality loss and no re-encoding. That’s a migration path no other modern format offers. Once Chrome ships support, JPEG XL becomes a production-ready option for the first time since its 2021 standardization.
Key Takeaways
- Developer pressure works: 1,000+ bug tracker upvotes, combined with PDF Association endorsement and browser competition, forced Google to reverse a three-year-old decision.
- JPEG XL is technically superior: Better detail preservation than AVIF at high quality, faster decoding, and unique lossless JPEG transcoding (20% size reduction).
- Cross-browser support likely by 2026: Safari ships it, Firefox is considering it, Chrome reversed course—mainstream adoption is finally within reach.
- Google delayed adoption by three years: The 2022 removal was premature and ignored clear developer demand. This reversal is an admission of that mistake.
- Standards bodies matter: PDF Association’s HDR endorsement gave Google political cover while creating long-term demand independent of browsers.
