Chromium Has Merged JpegXL

Original Article ↗ Hacker News Discussion ↗

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 unsafe blocks 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.