AVIF vs JPEG XL: a decision guide

JPEG XL (JXL) is, on the technical merits, one of the most capable still-image codecs ever standardised — and yet for web delivery in 2026 the correct default is still AVIF. Reconciling those two facts is the whole point of this guide, which sits under AVIF vs WebP Compression Benchmarks within Core Media Fundamentals & Next-Gen Formats. We compare the two formats on compression, lossless behaviour, progressive decode, and encode speed — then weigh those against the browser-support reality that decides which one you can actually ship.

Two different design philosophies

AVIF is a still frame of the AV1 video codec. It inherits AV1’s block-based, GPU-friendly decode path and its strong low-bitrate performance — which is why it excels at the aggressive compression targets web delivery cares about. It is not designed for authoring; it is designed for the last hop to the browser.

JPEG XL is a from-scratch image codec with a much broader remit: it was built for the entire imaging lifecycle, from camera capture through editing and archival to delivery. Its standout capabilities are lossless and visually-lossless modes, a genuinely progressive decode, extremely high resolution and channel-count ceilings, and — uniquely — the ability to losslessly transcode an existing JPEG into a JXL that is ~20% smaller and can be reversed bit-for-bit back to the original JPEG.

The consequence: JXL is often the better codec while AVIF is often the better web delivery format. Which one wins depends entirely on what you are optimising for — and, decisively, on where the file has to decode.

Feature and compression comparison

Tradeoff: On raw compression, the two trade blows by use case — AVIF pulls ahead at the small, low-bitrate end that dominates web images; JXL pulls ahead at high fidelity, lossless, and large sizes. If browser support were equal, you would pick per image type. It is not equal, and that single fact overrides most of the table for delivery.

The browser-support reality

This is the crux. JPEG XL’s compression advantages are moot in a browser that cannot decode it.

The history matters because it shapes the risk: Chrome shipped JPEG XL behind an experimental flag, then removed the code from stable in version 110, citing insufficient ecosystem interest and a preference for consolidating on existing formats. Firefox keeps a Rust decoder in Nightly behind a preference but has not shipped it to release. Only Safari 17+ decodes JXL in a shipping stable browser. So a real audience for image/jxl today is “recent Safari, and no one else.”

Warning: Do not ship image/jxl as a <picture> source expecting broad coverage. Outside Safari 17+, every stable browser skips it and falls through to your next source — so unless you also ship AVIF/WebP/JPEG behind it, most users get your worst fallback, not JXL’s compression. JXL as a source is only additive on top of a full AVIF chain, never a replacement for it.

Laid out on a timeline, the divergence is stark: AVIF shipped once per engine and stayed, while JXL’s only Chromium appearance was reverted.

The decision flow

When JPEG XL genuinely matters

JXL is not a bad choice — it is a narrow choice. It shines in exactly the places web delivery does not reach:

• Lossless JPEG transcode for storage. If you hold millions of legacy JPEGs, transcoding them to JXL shrinks the archive ~20% and is perfectly reversible — you can regenerate the original JPEG byte-for-byte on demand. This is a storage-cost and origin-egress win that never depends on the browser, because you serve the reconstructed JPEG (or AVIF) to the client.
• Authoring and archival masters. For a photography pipeline, JXL’s high bit depth, lossless mode, and progressive decode make it a strong intermediate/master format — you deliver an AVIF or JPEG derivative to the web.
• Safari-first audiences. A closed app or intranet where you control the client and it is Safari 17+ can serve JXL directly and reap its high-fidelity compression.

Tradeoff: Even where JXL is the better master, keep AVIF in your delivery pipeline. Storing JXL and serving AVIF is a perfectly coherent architecture: JXL optimises your archive, AVIF optimises the byte on the wire to the browser.

That two-layer split is worth drawing explicitly, because it is the shape almost every correct JXL deployment ends up in.

Why AVIF wins for web delivery today

1. It decodes everywhere that matters. Safari 16+, Chrome, Firefox, and Edge all ship AVIF in stable. JXL ships only in Safari 17+.
2. Its weakest point — encode speed — is a build-time cost. You pay avifenc’s slowness once in CI, not on every request.
3. Its no-progressive-decode limitation is mitigated by small file sizes plus a <picture> JPEG fallback for the slowest connections.
4. It reuses AV1 hardware. As AV1 video decode blocks proliferate, AVIF still-image decode rides the same silicon.

The one feature AVIF cannot match — reversible lossless JPEG transcode — is an origin/storage concern, not a delivery concern, so it does not change the delivery default.

Common mistakes and fixes

1. Shipping image/jxl as a primary <picture> source

Anti-pattern:

<picture>
  <source srcset="/img/hero.jxl" type="image/jxl">
  <img src="/img/hero.jpg" alt="Hero">
</picture>

Effect: Only Safari 17+ takes the JXL source; every other stable browser skips it and drops straight to the JPEG <img>, so the majority of users get the largest file on the page — the opposite of the intent.

Fix: Always place a full AVIF/WebP chain before falling back, and add JXL only as an additive first source if you specifically want to serve it to Safari 17+:

<picture>
  <source srcset="/img/hero.jxl" type="image/jxl">   <!-- Safari 17+ only -->
  <source srcset="/img/hero.avif" type="image/avif"> <!-- Safari 16+, Chrome, FF, Edge -->
  <source srcset="/img/hero.webp" type="image/webp"> <!-- Safari 14+, older Chromium -->
  <img src="/img/hero.jpg" alt="Hero" width="1200" height="630"> <!-- universal -->
</picture>

2. Assuming Chrome still supports JPEG XL behind a flag

Anti-pattern: Telling users to enable chrome://flags for JXL.

Effect: The decoder was removed from Chromium stable in version 110 — the flag no longer exists in release builds. Any strategy relying on it is dead.

Fix: Treat Chrome/Edge as having zero JXL support and Firefox as Nightly-only. Plan for Safari-only JXL delivery, or don’t deliver JXL at all.

3. Choosing JXL for tiny thumbnails to “save more bytes”

Anti-pattern: Encoding 200×200 product thumbnails as JXL for maximum compression.

Effect: At small sizes and aggressive web-quality targets, AVIF typically matches or beats JXL — and it actually decodes in the browser. You traded universal support for a nonexistent gain.

Fix: Use AVIF for small, low-bitrate web images; reserve JXL for high-fidelity or lossless masters.

4. Replacing an AVIF pipeline with JXL because “it’s newer/better”

Anti-pattern: Migrating delivery from AVIF to JXL on technical-superiority grounds.

Effect: You strand the majority of your audience on the JPEG fallback and lose the compression you had with AVIF.

Fix: Keep AVIF for delivery; adopt JXL, if at all, at the storage/archival layer where the browser is not in the loop.

5. Forgetting the MIME type for .jxl

Anti-pattern: Serving .jxl files without registering image/jxl.

Effect: Even Safari 17+ will refuse the file if it arrives as application/octet-stream.

Fix: Register image/jxl on the origin exactly as covered in the MIME type configuration guide, and verify with curl -I.

Related

• AVIF vs WebP Compression Benchmarks — the SSIM/PSNR data and encode workflow behind AVIF’s delivery advantage
• How to configure AVIF fallbacks for Safari 14 — the AVIF → WebP → JPEG cascade that any JXL source must sit on top of
• When to use WebP over JPEG in production — the universal-fallback tier of the same delivery chain
• MIME type configuration for modern media servers — registering image/avif and image/jxl so the right decoder is invoked
• Core Media Fundamentals & Next-Gen Formats — parent section covering next-generation format strategy end to end