JPEG XL vs AVIF in 2026: Why Browsers Picked Different Winners
Safari ships JPEG XL, Chrome shipped AVIF. Five years in, here's what each format actually does well and which one your project should bet on.
Alex Thompson·May 8, 2026·9 min read
The Browser Standoff Nobody Resolved
Five years after both formats hit beta, the web still has two competing successors to JPEG. Apple ships JPEG XL across Safari, Photos, and Preview. Google shipped AVIF in Chrome and removed JPEG XL support in 2022. Firefox sits between them, with AVIF on by default and JPEG XL behind a flag.
If you serve images on the web in 2026, this isn't an academic question. The format you pick determines which half of your users get the fast version and which half get the fallback. Our image compressor supports both, but knowing which to ship matters more than which tool produced it.
Try these conversions
Free, in your browser — no signup, files auto-delete in 2 hours.
JPEG XL and AVIF were both designed to replace JPEG. They take very different paths to get there.
JPEG XL is a from-scratch codec by Cloudinary and Google's research team. It supports lossless and lossy compression, animation, HDR, wide color, and progressive decoding. It can losslessly recompress existing JPEG files, shrinking them by about 20% with no quality change. That last property is unique.
AVIF is the still-image profile of the AV1 video codec. It inherits AV1's compression strength (very strong at low bitrates) but also AV1's encoding cost (slow). AVIF is what you get when you take a frame out of a modern video codec and call it an image format.
Capability
JPEG XL
AVIF
Lossless mode
Yes (excellent)
Yes (decent)
Lossy compression
Strong
Stronger at low bitrates
Animation
Yes
Yes
HDR / 10-bit / 12-bit
Yes
Yes
Wide color (Rec.2020, P3)
Yes
Yes
Progressive decoding
Yes
No
JPEG recompression
Yes (lossless)
No
Encoding speed
Fast
Slow
Decoding speed
Fast
Moderate
Max image dimensions
1,073,741,823 px
65,536 px
The progressive decoding gap matters for slow connections. JPEG XL renders a low-quality preview as bytes arrive, sharpening as more data loads. AVIF either shows nothing or shows the full image. On a 2G mobile connection, that's a real UX difference.
Browser Support in 2026
The numbers as of mid-2026:
AVIF: Chrome (since 85), Edge (since 121), Firefox (since 93), Safari (since 16, partial). Roughly 95% of global traffic.
JPEG XL: Safari 17+ (since 2023), Edge (behind flag), Firefox (behind image.jxl.enabled), Chrome (removed in 2022). Roughly 35% of traffic if you count Safari.
If you ship JPEG XL today, you're shipping for Apple users only. That's 20-30% of most consumer web traffic, higher in luxury and design verticals. AVIF reaches almost everyone.
Pro Tip: The <picture> element lets you serve both. List JPEG XL first, AVIF second, JPG fallback last. Browsers pick the first format they support. Our JPG to WebP converter covers similar <picture> patterns for older fallbacks.
File Size in Practice
Real-world numbers from a typical 2400x1600 photograph:
Format
File size
Visual quality
Original JPG (q=90)
1.2 MB
Reference
JPG (q=80)
720 KB
Slight softening
WebP (q=80)
480 KB
Matches JPG q=85
AVIF (q=63 in libavif)
220 KB
Matches JPG q=85
JPEG XL (distance=1.0)
280 KB
Matches JPG q=90
JPEG XL lossless from JPG
920 KB
Identical to source
For lossy compression at the same quality, AVIF wins on file size. JPEG XL is close behind, with better encoding speed and progressive rendering as the trade-off.
For lossless work, JPEG XL is dramatically better. Lossless AVIF is functional but bloated. Lossless JPEG XL is the smallest practical lossless format on the web today.
When to Pick AVIF
Pick AVIF in 2026 if:
Your audience is consumer web (Chrome dominant)
You serve a CDN with on-the-fly conversion
You can absorb 5-10x slower encoding on the publish step
You ship <picture> with JPG fallback for the long tail
Your goal is smallest possible file at acceptable quality
AVIF is the safe pick for 2026 production. Cloudflare, Imgix, Cloudinary, and Vercel all output AVIF on demand. Encoding cost is a one-time problem you push to the CDN.
When to Pick JPEG XL
Pick JPEG XL if:
Your traffic skews Apple (luxury, design, photography portfolios)
You need lossless compression (graphic design, archival, print)
You want to recompress JPG without re-encoding (saves 20% storage)
You can serve both formats and let browsers negotiate
JPEG XL is also the right pick for archival. The losslessly-from-JPG conversion path means you can shrink your photo library without ever decoding the originals. Convert when you store, decode back to JPG when you need the universal format.
Real Workflow: Photographer Portfolio
A wedding photographer asked me how to publish 4000 RAW exports as a portfolio. The math works out like this:
4000 photos at 12 MB JPG each = 48 GB
Same 4000 as AVIF q=63 = 8.8 GB (5.5x smaller)
Same 4000 as JPEG XL d=1.0 = 11 GB (4.4x smaller)
Same 4000 as JPEG XL lossless from JPG = 38 GB (1.3x smaller, identical quality)
For a Squarespace site, AVIF saves the most bandwidth. For a backup of "the JPGs I might re-edit," JPEG XL lossless beats anything else. We cover the upstream RAW step in How to Convert ARW to JPG and the format-comparison view in AVIF vs WebP vs JPEG XL.
Speed 0 is slowest and best, speed 10 is fastest and worst. Speed 4 is the production sweet spot. Quality 63 in cavif maps to roughly JPG q=85. Lower numbers reduce file size.
Distance is butteraugli units. Distance 1.0 is "indistinguishable from source," distance 0.0 is mathematically lossless. Effort 7 is the publishing default. Effort 9 is slower and slightly smaller.
For JPEG-to-JXL lossless recompression:
cjxl input.jpg output.jxl --lossless_jpeg=1
This runs in milliseconds and produces a file 20% smaller with the original JPG bit-perfectly recoverable.
Browser DevTools "Save image as" can output WebP from any source on Chrome
JPEG XL conversion tools are scarcer. Sharp doesn't ship JXL by default. ImageMagick and libvips have JPEG XL support, but you need to compile against libjxl. The cjxl reference tool is the most reliable production path.
What About WebP?
WebP is now seven years old and shipped on every major browser. If your goal is "better than JPG, works everywhere, no <picture> element needed," WebP is still correct in 2026. It's the boring answer.
The case for AVIF over WebP is roughly 30% smaller files at the same quality. The case for JPEG XL over WebP is lossless mode and JPG recompression. Neither wins on universal compatibility.
The Chrome team's stated reason for removal was insufficient incremental benefit over AVIF. Apple's continued investment changes the calculation. There's no announced timeline, but the feature flag remains in Chromium. Re-enabling it is a one-line change if priorities shift.
Can I serve JPEG XL with a JPG fallback?
Yes. Use the <picture> element with <source type="image/jxl"> first and <img src="fallback.jpg"> last. Browsers that don't recognize the type fall through to the JPG. No JavaScript needed.
Does AVIF support transparency?
Yes, AVIF has full alpha channel support. So does JPEG XL. Both formats handle transparency at the same quality as their lossy modes. Use them where you'd previously have used PNG with alpha.
Why is my AVIF encoding so slow?
AVIF inherits AV1's encoding cost. A 4000-pixel photo can take 2-10 seconds even on a fast machine. Use lower speed/effort settings or batch encode overnight. CDN-side encoding (Cloudflare Images, Cloudinary) is the standard production answer.
Is JPEG XL lossless really the same as the source JPG?
Yes, bit-for-bit identical when you decode back to JPG. The --lossless_jpeg mode rearranges the existing JPG data into a more efficient JXL container without reprocessing the pixels. You can verify with cjxl input.jpg output.jxl --lossless_jpeg=1 && djxl output.jxl recovered.jpg && diff input.jpg recovered.jpg.
What about HEIC?
HEIC and AVIF use different parts of the same MPEG container family. HEIC is what iPhones write, AVIF is what browsers read. Apple uses both for different purposes. We cover the iPhone-specific path in HEIC to JPG batch conversion.
For 2026 production web: AVIF with a JPG fallback. The browser support is universal in practice and CDN encoding is widely available. For Apple-heavy audiences or lossless workflows: JPEG XL is the better tool. For "just works everywhere with no thinking": WebP is still defensible.
If you're picking now, run an A/B test with both formats on your actual content. Encoder defaults vary, and your content type (graphics vs photographs vs UI) shifts which format wins. Our JPG to AVIF converter and JPG to WebP converter cover the two practical web paths.
