Chromium Has Merged JpegXL
Chromium is adding support for the JPEG XL image format, reigniting debate over how it compares to existing formats like WebP, AVIF, JPEG, PNG, and GIF. Commenters highlight JPEG XL’s strengths—high-quality and lossless compression, progressive decoding, HDR and wide-gamut support, animation, and efficient JPEG recompression—while weighing them against concerns about codec complexity, long-term maintenance, and security, which are partly addressed by a new Rust-based implementation. Many see Chrome’s move as a key step toward broader ecosystem adoption, even as tool support, hardware acceleration, and real-world usage patterns are still catching up.
Why Chromium Previously Rejected JPEG XL & Why It’s Back
- Several commenters tie earlier rejection to security and maintenance concerns:
- libjxl was seen by some as a large, unsafe C++ codebase increasing attack surface.
- Others counter it was actively maintained; the real blocker was its use of C++ instead of Rust/WUFFS, which Chromium prefers for parsers.
- Chrome’s stance was that each new format:
- Adds a permanent maintenance and security burden.
- Duplicated much of what AVIF already offered.
- Some claim there was also a strategic push to favor AVIF (used elsewhere in Google), but others call this speculation and point to public security/duplication arguments instead.
- The new Rust-based implementation (jxl-rs) is viewed as the enabling change; it addresses memory-safety concerns and appears mature enough to integrate.
Codec Comparisons: WebP, AVIF, JPEG XL, JPEG, PNG, GIF
- WebP:
- Effectively “free” when VP8 decoders already exist; has hardware acceleration on major mobile platforms.
- Very fast encoding; good practical tradeoff for today’s web.
- Has had serious vulnerabilities; some odd encoder edge cases reported.
- AVIF:
- Good at very low bitrates; very slow encoders in practice, especially at high effort.
- Limited hardware decode support on phones so far.
- JPEG XL:
- Claimed to beat AVIF on quality/size, especially at high quality and in lossless mode.
- Supports progressive decoding, wide color gamut, HDR, high bit depth, arbitrary channels, animation, and JPEG lossless transcoding with ~20% savings.
- Animation is intra-frame only, so inefficient compared to real video.
- Legacy formats:
- JPEG/PNG still dominate due to ubiquity and tooling; many publishers don’t optimize aggressively.
- GIF is widely seen as obsolete for animation; video or animated WebP/AVIF/APNG is recommended.
Security, Rust, and “Unsafe”
- Strong agreement that image codecs are primarily risky for memory issues; Rust is seen as a big win there.
- Some warn against equating memory safety with overall security or treating Rust as a “free audit.”
- Presence of
unsafeblocks in Rust code is discussed; consensus is that judicious, documented use is acceptable.
Hardware, Performance & Adoption
- WebP’s current hardware acceleration is argued to make it faster and more battery-efficient in practice, even if JXL compresses better.
- Others note that extra bytes over the network also cost power, so format choice is a tradeoff.
- Cloudinary benchmarks cited: JPEG XL often Pareto-optimal on quality/size, though they don’t reflect hardware decoders and depend on imperfect metrics.
- Many tools and platforms now support JXL (Apple OSes, some editors, MS add-on), but messaging apps and some OS viewers still lag.
- Several expect a multi-year adoption curve; Chromium support is seen as a necessary step for JPEG XL to become mainstream, even for non-Chrome users.
Standardization & Workflow Concerns
- Frustration that the JPEG XL spec is behind an ISO paywall; more general criticism of non-public standards.
- Some dislike formats that can be both lossy and lossless, fearing accidental data loss; others respond that “lossless vs lossy” is a workflow property, not a format property, and PNG workflows can be lossy in practice too.