JPEG XL vs. AVIF for web use-cases

Original Article ↗ Hacker News Discussion ↗

Image engineers are weighing JPEG XL against AVIF as next‑generation formats for the web, finding that today’s AVIF encoders generally produce smaller files at web‑typical quality levels, especially for screenshots, illustrations, and animated content. JPEG XL is seen as stronger for lossless and very high‑quality images, archival use, high bit depth, and seamless transcoding of existing JPEGs, but its tooling and encoders are less mature. Much of the debate centers on real‑world deployability—browser and site support, container compatibility, encoder evolution, and how earlier platform decisions (notably by Chrome) distorted the pace and direction of adoption.

AVIF container & deployment concerns

  • Some argue AVIF’s container-based design aids long-term deployment: sites only need “AVIF” once; future codecs (AV2, etc.) could reuse the container while browsers upgrade decoders.
  • Others counter that containers don’t help if the client lacks the codec: without a decoder you still get a broken image.
  • Real bottleneck is often site-side logic (content-type whitelists, image pipelines) lagging browser support; containers may reduce repeat integration work, but content negotiation and codecs parameters remain relevant and messy.

Compression performance & use-cases

  • Consensus from the thread: for typical web-quality lossy images and especially for screenshots/illustrations, AVIF currently wins on size–quality tradeoff and speed.
  • JPEG XL is seen as stronger for:
    • Lossless and “near-lossless” high-quality images.
    • Archival/transcoding of existing JPEGs without additional loss, while shrinking them.
    • Very high bit-depth and large-resolution imagery, photography, and non-web domains.
  • Some note JPEG XL catches up or slightly wins at very high quality levels, but that’s less common for bandwidth-sensitive web delivery.
  • Several commenters still prefer AVIF for personal collections and screenshots; others plan to use JPEG XL for archives and editing-friendly images.

Encoders, metrics & format potential

  • Multiple comments stress the comparison reflects encoder maturity, not theoretical format limits.
  • AV1/AVIF encoders have improved steadily for years; JPEG XL encoders stagnated, split effort, or targeted different goals.
  • Some claim JPEG XL is fundamentally more constrained; others call this an educated but non-authoritative guess.
  • Perceptual metrics (SSIMULACRA2, Butteraugli) guide tuning, but can diverge from human preference. One encoder tuned heavily to a metric reportedly looks worse subjectively in some cases.
  • Faster and GPU-accelerated JPEG XL encoders and new Rust tooling are emerging; there’s optimism JPEG XL could still improve notably.

Animation, progressive rendering & UX expectations

  • Strong sentiment that “animated image formats” (animated JXL, AVIF-as-GIF) are inferior to true video for motion and playback efficiency.
  • Counterpoint: GIF-like animations have different UX expectations (no controls, looped, treated as images), so image-based animation remains useful.
  • AVIF now supports good progressive rendering; this narrows one of JPEG XL’s perceived web advantages.
  • Some care deeply about zoomed-in detail and highlight preservation; others find current AVIF artifacts acceptable for typical viewing.

Implementation, security, and ecosystem politics

  • Browsers are cautious about adding codecs due to maintenance, binary size, and attack surface; this motivates Rust-based decoders and limits “plethora of formats” support.
  • Proposals for pluggable codecs or sandboxed decoders surface, but browser vendors worry about safety and complexity.
  • Several comments criticize how one dominant browser’s earlier rejection of JPEG XL chilled its development and adoption, then later comparisons portray JPEG XL as “late and worse.”
  • AVIF/AV1 patent risk is mentioned; JPEG XL is seen as cleaner so far, though this is not deeply explored.