Shipping JPEG XL in Chrome
- ID
- 32839
- Status
- summarized
- Published
- 07 Oct 2026, 7:25 PM
- Fetched
- 08 Oct 2026, 12:50 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://developer.chrome.com/blog/jpeg-xl-in-chrome
- Source URL
- https://hnrss.org/best
Summary
- Score
- 6.5
- Created
- 08 Oct 2026, 12:51 AM
- Tags
- Audience
- developersvibe_coderssaas_founders
What happened
Chrome is shipping decode support for JPEG XL (.jxl) starting in Chrome 155, per a Chrome for Developers blog post published October 6, 2026 by Luca Versari, Moritz Firsching, and Philip Jägenstedt. The post claims 30-50% better compression than JPEG plus lossless compression, built-in HDR support, and lossless JPEG transcoding, and says Chrome recommends trying both AVIF and JPEG XL rather than picking one. The decoder is a from-scratch pure-Rust implementation (jxl-rs) with a SIMD abstraction layer (jxl_simd) inspired by the C++ Highway library from libjxl, which required stabilizing the Rust target_feature_11 feature so SIMD could be used without unsafe code.
Why it matters
This is decode-only, so it changes what you can accept from users and third parties, not what you can cheaply produce: if your pipeline already handles AVIF, Chrome 155+ means you can serve .jxl to Chrome clients and keep AVIF/JPEG fallbacks for everything else, and you can A/B the two on your own photographic or lossless assets instead of trusting the 30-50% claim. The Rust-rewrite detail is the transferable one for anyone shipping a parser of untrusted binary input: Chrome's stated reason is that C++ decoders have historically produced out-of-bounds reads, heap overflows, and use-after-free bugs, and sandboxing is treated as only a secondary layer.
Discussion angle
Run one real image from your own product through AVIF and JPEG XL and compare size, decode time, and quality at the settings you'd actually ship — then argue whether a decode-only Chrome 155 rollout is enough to justify adding a third format to your CDN and fallback logic.