JPEG XL vs AVIF in 2026: Chrome Ships JXL, but AVIF Still Makes Smaller Files

JPEG XL now works in every major browser. Chrome 155 started decoding it on October 6, 2026, Firefox 158 turned it on by default a week later, and Safari has had it since 17.0. So the obvious question is whether you should add image/jxl to your tags and switch over.

For most of your site, no. Two days after Firefox shipped, Jake Archibald published the most thorough JPEG XL vs AVIF comparison for web use-cases I've read, and for the ordinary lossy photos, screenshots and illustrations that make up a website, AVIF still produces smaller files and decodes faster. At default effort, the best JPEG XL encoder typically made photos 15–25% larger than AVIF.

JPEG XL does win in a few places that matter (lossless, recompressing old JPEGs, some HDR). I'll go through his numbers, then the markup I'd actually ship, plus a couple of points from the lobste.rs thread.

How he tested JPEG XL vs AVIF

The setup is careful enough that you can't wave the results away as one person's opinion:

Encoders: avifenc 1.4.2, cjxl from libjxl 0.12.0, jixel 0.4.2 (a newer JPEG XL encoder), and cwebp 1.6.0 for lossless WebP
Most images encoded at 1598px wide, 2x the blog's max display width (plus an 18 MP version of the F1 shot)
Files compared at matched quality using SSIMULACRA2 (50 = medium, 70 = high, 80 = very high, 90 = visually lossless), with ColorVideoVDP as a second metric
Hardware: M4 Pro MacBook Pro

He compares encoders at equal quality, so he never sets both to "quality 80" and then compares bytes. That is the only fair way to do it.

File sizes: AVIF wins most of the table

| Image (SSIMULACRA2 target) | AVIF | libjxl | jixel |
|---|---|---|---|
| F1 photo (70) | 41.4 kB | 58.4 kB (+41%) | 46.6 kB (+12%) |
| People (70) | 63.8 kB | 95.5 kB (+50%) | 70.9 kB (+11%) |
| Red panda (70) | 99.6 kB | 121.5 kB (+22%) | 101.7 kB (+2%) |
| Weasel (60) | 223.0 kB (+30% vs jixel) | 213.0 kB (+24% vs jixel) | 172.0 kB |
| Screenshot (80) | 20.7 kB | 34.1 kB (+65%) | 25.4 kB (+23%) |
| Illustration (80) | 68.5 kB | 139.8 kB (+104%) | 110.4 kB (+61%) |
| Alpha (70) | 50.4 kB | 78.6 kB (+56%) | 119.1 kB (+136%) |
| Small F1 (70) | 8.3 kB | 10.7 kB (+29%) | 9.5 kB (+14%) |
| F1, 18 MP (70) | 146.7 kB | 257.8 kB (+76%) | 184.7 kB (+26%) |

Summary by category:

Photos: at default effort the best JPEG XL result is 15–25% larger than AVIF. At max effort it's 6–20% larger. The weasel is the one photo where jixel wins clearly.
Screenshots and illustrations: JPEG XL is 30–90% larger at default effort and 20–70% larger at max.
Transparency: libjxl is 31–44% larger at default effort and 61–70% larger at max. jixel always encodes alpha losslessly, so it ends up 1.9–3.1x the size of AVIF.

On photos jixel gets a lot closer to AVIF than libjxl does, so if you test JPEG XL with nothing but cjxl you're testing the weaker encoder. Even jixel is still behind AVIF, though.

Encode and decode speed: JPEG XL is slower too

A lot of people assume JPEG XL is the fast one. Jake's measurements on the F1 photo don't back that up:

jixel's default is 12–36% faster to encode than AVIF, but its files are 14–18% larger.
To match AVIF's default file size, jixel extraslow takes 18–27x as long and uses about 10x the memory.
libjxl's default takes 1.5–2x AVIF's encode time and still produces bigger files.
Decoding JPEG XL takes 2–3x as long as AVIF at medium quality, and about 1.5–1.8x at very high quality. Safari's JPEG XL decoder is the slowest of the three.

For a build pipeline that re-encodes thousands of images, those multipliers show up directly in CI time.

Progressive loading: JPEG XL's big feature is a ~2 kB blur

Progressive decoding has always been JPEG XL's best argument. Chrome and Firefox render progressive JPEG XL. Safari shows the final image and no intermediate passes.

Jake doesn't think much of it in practice. The first pass is "a BlurHash-like preview" at about 2 kB, and it doesn't match what AVIF's preview shows until roughly 63 kB has arrived. The progressive AVIF F1 preview is about 11.5 kB. Progressive AVIF has its own costs: it renders progressively only in Chrome (a Firefox patch is in progress), and it decodes 29–44% slower there. Even so, progressive AVIF decoded 1.6–6x faster than the progressive JPEG XL equivalents.

If all you get early is a blur, you can inline a 2 kB placeholder yourself today, in any format.

Where JPEG XL beats AVIF

There are three cases where JPEG XL comes out clearly ahead:

Lossless. libjxl gives the smallest lossless files on most images. Lossless WebP is 9–17% larger on photos, and lossless AVIF is 33–122% larger. libjxl's default encode takes 0.1–0.5 s.

JPEG transcoding. You can repack an existing JPEG into JPEG XL losslessly and get a 9–20% smaller file, with bigger savings at higher resolutions. If you have a CDN full of old JPEGs, that's a free saving you can reverse later:

bash

   cjxl photo.jpg photo.jxl           # lossless JPEG recompression is the default for JPEG input
   djxl photo.jxl photo-restored.jpg  # gives you back the original JPEG bytes

HDR with PQ. By HDR SSIMULACRA2, jixel's default ranges from 8% smaller to 3% larger than PQ AVIF, and ColorVideoVDP rates libjxl 28–53% smaller. No browser supports JPEG XL gain maps yet, and Firefox decodes HDR JPEG XL about 4x slower than AVIF.

Google's own launch post lands in the same place. It recommends "trying both AVIF and JPEG XL" and expects JPEG XL to be "most helpful for high-fidelity or lossless compression," so even Google isn't pitching it for your hero images at q70.

Animated AVIF or JPEG XL? Use a video

Animated AVIF came out at 725 kB and animated JPEG XL at 2.17 MB at the same ColorVideoVDP score. Animated AVIF is basically AV1 video, while JPEG XL encodes every frame on its own. Animated AVIF also plays badly in Chrome and Safari. Use .

Browser support for JPEG XL vs AVIF, October 2026

| | AVIF | JPEG XL |
|---|---|---|
| Chrome | since 85 | 155 (jxl-rs decoder, Oct 6 2026) |
| Firefox | since 93 | 158, on by default (Oct 13 2026) |
| Safari | since 16.0 on iOS, 16.1 on macOS (full support from 16.4) | since 17.0, no progressive rendering |
| Progressive rendering | Chrome only | Chrome, Firefox |
| HDR gain maps | supported, Jake's pick for HDR | in the format, but no browser decodes them |

Chrome and Firefox now use the same Rust decoder, jxl-rs, which helps with interop. Google's post says the Rust decoder was picked for memory safety. Anyone still on Chrome below 155 or on Firefox ESR won't get JPEG XL, so you need a fallback either way.

What to put in your tag today

On lobste.rs, someone suggested listing every format and letting the browser choose. Jake replied that "the browser picks the first valid ." The order of your sources is still you choosing a format. Adding JPEG XL above AVIF means Chrome 155+ and Firefox 158+ download the larger, slower-to-decode file.

For lossy photos, screenshots and illustrations:

html

<picture>
  <source type="image/avif" srcset="hero.avif">
  <img src="hero.jpg" alt="..." width="1598" height="900">
</picture>

Encode at 4:4:4, which is what avifenc picks by default for PNG input. Jake found 4:2:0 rarely saved bytes and made his transparent test image 4–27% larger. Use the highest effort your build can afford. A starting point based on the quality setting from his stability test, with a slower speed:

bash

avifenc -q 50 -s 5 input.png output.avif

He reports -s 5 gives about 10% smaller files than the default for about 3x the encode time on his F1 test image. Raise or lower it depending on how many images you encode.

Use JPEG XL when:

you're serving lossless images (put image/jxl first and a PNG or WebP fallback after it)
you're recompressing a legacy JPEG archive
an AVIF file comes out unusually large, which is the exact fallback Jake suggests. Try jixel on that image.

kangalio's one-line summary in the thread is the version I'd keep: "AVIF for deployed images, JPEG XL for source images."

The caveat: it all depends on the metric

Another commenter re-ran the tests with Butteraugli and found it favors JPEG XL at higher qualities. Jake said he used ColorVideoVDP specifically to avoid metrics the encoders tune for, and that jixel is "hyper-tuned to metrics." That argument isn't settled, and about ten test images is a small sample. Jake says to test your own images, and he's right.

Still, the timing is funny. Google deleted JPEG XL from Chromium in late 2022, shipped it again in 2026, and the best independent benchmark of the year says to keep serving AVIF for most things. I don't think bringing JPEG XL back was a mistake. I'd use it for archives and lossless work, and keep AVIF for the lossy images a website actually serves.

What are you serving in production right now: AVIF, JPEG XL, WebP, or plain JPEG? And what numbers would get you to switch? If you've run your own images through jixel and seen something different, post the sizes in the comments.

Sources

Jake Archibald, JPEG XL vs AVIF for web use-cases (Oct 2026)
lobste.rs discussion
Chrome for Developers, Shipping JPEG XL in Chrome (Oct 6, 2026)
Phoronix, Firefox 158 released with JPEG-XL support by default (Oct 12, 2026)
jxl-rs and libjxl repos
Can I use: AVIF and Can I use: JPEG XL