Frontend Performance

JPEG XL Support and Fallbacks: Should You Serve It Today?

This guide extends Serving AVIF and WebP with Fallbacks, part of Image & Media Optimization. JPEG XL (JXL) is a modern image format with attractive properties: excellent quality per byte at high fidelity, progressive decoding, wide-gamut and HDR support, and a unique feature — lossless recompression of existing JPEGs, typically about 20% smaller with bit-exact reconstruction of the original file.

Its weakness is browser support. Safari supports JPEG XL; Chromium removed its experimental support years ago and its future there has been debated; Firefox support has existed behind flags. That makes JXL a format you can add safely — using <picture> or Accept negotiation so only supporting browsers receive it — but not one you can rely on as a primary format. The question is whether the gains for supporting browsers justify the extra pipeline and storage.

JPEG XL vs AVIF vs WebP Comparison of JPEG XL, AVIF and WebP across browser support, high-fidelity efficiency, progressive decoding and JPEG recompression. JPEG XL vs AVIF vs WebP Aspect JPEG XL AVIF WebP Browser support Safari mainly all modern all modern High-fidelity efficiency excellent very good good Progressive decoding yes limited no Lossless JPEG recompression ~20% smaller, exact no no

Rapid Diagnosis

  • Check your audience's browsers. The share of Safari (macOS and iOS) traffic determines how many users could benefit.
  • Check your image quality targets. JXL's advantage is largest at high quality (photography, product detail); at aggressive compression AVIF is often competitive or better.
  • Check whether you store original JPEGs. Lossless recompression is a storage and bandwidth win for large JPEG archives.
  • Check pipeline capacity. Each additional format adds encode time and storage per variant.

Root Cause Analysis: Why JXL Is Considered

1. High-fidelity photography. Sites where image quality is the product (photography, art, real estate) pay heavily in bytes for high-quality images; JXL can reduce that substantially at the same quality.

2. Large JPEG archives. Lossless recompression saves bandwidth without any quality decision.

3. Progressive rendering. JXL can render a useful preview early from a partial download, improving perceived speed for large images.

4. Uncertain support. All of the above only applies to browsers that decode JXL, so the gain is proportional to that audience.

Bytes for a high-quality 1600px product photo Bar chart comparing file size for one high-quality product photo in JPEG, WebP, AVIF and JPEG XL at similar visual quality. Bytes for a high-quality 1600px product photo JPEG (q85) 310KB WebP (q85) 228KB AVIF (q60) 166KB JPEG XL (d1.0) 158KB JXL lossless from JPEG 250KB

Step-by-Step: Adding JXL Safely

1. Encode JXL alongside existing formats

bash
# Lossy JXL at high fidelity (distance 1.0 ≈ visually lossless).
cjxl hero.png hero.jxl -d 1.0 -e 7
# Lossless recompression of an existing JPEG (bit-exact, reversible).
cjxl product.jpg product.jxl --lossless_jpeg=1
# trade-off: higher effort (-e) improves compression but slows encoding; effort
# 7 is a common balance for build pipelines.

2. Serve with picture, JXL first

html
<picture>
  <source type="image/jxl" srcset="/img/p42-800.jxl 800w, /img/p42-1600.jxl 1600w" sizes="(max-width: 700px) 100vw, 700px">
  <source type="image/avif" srcset="/img/p42-800.avif 800w, /img/p42-1600.avif 1600w" sizes="(max-width: 700px) 100vw, 700px">
  <source type="image/webp" srcset="/img/p42-800.webp 800w, /img/p42-1600.webp 1600w" sizes="(max-width: 700px) 100vw, 700px">
  <img src="/img/p42-1600.jpg" width="1600" height="1200" alt="Leather boot, side view">
</picture>
<!-- trade-off: every extra <source> adds HTML bytes for every image; on pages
     with many images, Accept-header negotiation at a CDN keeps markup small. -->

Browsers pick the first type they support, so Safari receives JXL, others AVIF.

3. Or negotiate at the CDN with Accept

An image CDN or edge function can inspect Accept: image/jxl,image/avif,... and return the best supported format from a single URL, with Vary: Accept.

javascript
// Edge function sketch: choose format from Accept.
const accept = request.headers.get('accept') || '';
const fmt = accept.includes('image/jxl') ? 'jxl' : accept.includes('image/avif') ? 'avif' : accept.includes('image/webp') ? 'webp' : 'jpg';
// trade-off: Vary: Accept fragments the cache by Accept header string; normalise
// it to a small set of format keys in the cache key to keep hit rates high.

4. Measure who actually benefits

Log the format served per request (or currentSrc extension in RUM) and compute bytes saved for JXL-capable users. If the benefit is small, simplify.

Should you add JPEG XL? Decision sequence for whether adding JPEG XL to an image pipeline is worthwhile. Should you add JPEG XL? Large share of Safari traffic and quality-critical photos? Add JXL first in picture or via CDN negotiation yes no Large archive of original JPEGs? Consider lossless JXL recompression for supporting browsers yes no Image CDN already supports JXL? Enable it — near-zero effort yes no Stay with AVIF + WebP + JPEG

Verification

In Safari, currentSrc should end in .jxl (or the response Content-Type should be image/jxl with negotiation); in Chromium, AVIF. Compare transferred image bytes for Safari sessions before and after in RUM. Visually compare JXL outputs against your quality bar.

Worked Example: A Photography Portfolio Platform

A portfolio platform served high-quality JPEGs (q90) because photographers complained about AVIF artefacts in fine textures at lower settings. About 38% of visitors used Safari. Adding JXL at distance 0.8 for Safari (via the image CDN's Accept negotiation) cut image bytes for those visitors by 34% with no quality complaints; AVIF at a conservative quality served others. Total CDN egress dropped 13%, and LCP p75 for Safari users improved by 180ms on mobile.

Format Strategy Beyond JXL

Format choice is one lever among several, and usually not the largest. Right-sizing images (serving 800px instead of 2400px) typically saves more than any format switch, and correct priority hints save more time than any byte reduction. Treat JXL as a refinement for image-heavy, quality-sensitive sites with a meaningful Safari audience — after responsive sizing, AVIF/WebP and LCP prioritisation are in place. For most sites, AVIF with WebP and JPEG fallbacks remains the pragmatic default.

Keeping the Option Cheap to Maintain

The main cost of JPEG XL is operational, not technical. Each extra format adds a column to every image's variant matrix: more encode time in CI, more objects in storage, more cache entries at the CDN, and one more thing to check when a template changes. Keep that cost small with three habits. First, generate JXL only for the image classes where it matters — hero and product photography — and leave thumbnails, icons and illustrations on AVIF and WebP. Second, put the format list in one shared helper or CDN preset, so removing JXL later (or promoting it if Chromium support returns) is a one-line change rather than a template hunt. Third, review the RUM numbers every quarter. If JXL-capable sessions shrink, or the bytes saved per session fall below what the extra storage and build minutes cost, drop the format without regret. Because every request already has a fallback, removing JXL has no visible effect on users.

Common Mistakes

  • Serving JXL without fallbacks. Breaks images for most browsers.
  • Putting JXL after AVIF in picture. Safari supports both and will take the first match.
  • Negotiating without Vary. Caches may serve JXL to browsers that cannot decode it.
  • Assuming universal gains. At low quality settings, AVIF can match or beat JXL.

Edge Cases

Progressive JXL and LCP. Progressive previews may paint early, but LCP accounting for progressive paints varies; do not rely on it for metrics.

Wide gamut and HDR. JXL supports them well; serve them only where colour management is correct end to end.

Social and email previews. Use JPEG for og:image and email; scrapers rarely support JXL.

Storage costs. Each extra format multiplies variants; budget storage before generating JXL for every width.

FAQ

Does Chrome support JPEG XL?

Chromium removed its earlier experimental JXL support, and its status has been debated since. Check current support tables before relying on it; design your serving so JXL is an optional enhancement.

Is lossless JPEG recompression really lossless?

Yes — the original JPEG can be reconstructed bit for bit from the JXL file. That makes it safe for archives where originals must be preserved.

Is JXL better than AVIF?

At high fidelity and for progressive decoding, often yes; at aggressive compression levels, AVIF is frequently comparable or better. The bigger difference today is browser support.

Does adding JXL slow down builds?

Encoding JXL is generally faster than AVIF at comparable effort, but every additional format adds time and storage. Cache outputs by content hash.

How do I detect JXL support in JavaScript?

Decode a tiny JXL data URI in an Image and check whether it loads, or rely on <picture> and server negotiation, which avoid script-based detection entirely.

Should the LCP image be served as JXL?

If the browser supports it and it is smaller at your quality target, yes, via the same <picture> or negotiation. Keep fetchpriority="high" and preloading consistent: a preload for the AVIF file would be wasted on Safari if it then uses JXL.