WebP vs AVIF vs JPEG XL: Which Image Format Should You Use in 2026?

Updated September 2026. We rebuilt this comparison from scratch: three real images from our portfolio, encoded to JPEG, WebP, AVIF and JPEG XL on one machine, compared at the same visual quality rather than the same "quality" setting, with browser support checked against caniuse data on 25 September 2026.

The short answer

• AVIF is the best default for web images in 2026. At the same visual quality as a JPEG saved at quality 80, our AVIF files were 37% to 67% smaller, and about 95% of web users have a browser that can display AVIF.
• WebP is a safe fallback, but it isn't always smaller than JPEG. It halved the size of a flat interface screenshot, but on one of our photos it needed a bigger file than JPEG to look as good.
• JPEG XL compresses brilliantly at high quality (up to 65% smaller than JPEG in our tests) and can shrink existing JPEGs with no quality loss at all. But only Safari displays it by default today, so it can't be your only format yet.
• Serve AVIF first, with WebP or JPEG as the fallback, using the <picture> element. Add JPEG XL as an extra source if you run a photography-heavy site and have the pipeline for it.

Browser support in September 2026

These figures come from caniuse data updated on 24 September 2026. "Global support" is caniuse's estimate of the share of web users whose browser can display the format.

JPEG XL has had a bumpy ride. Chrome first added it behind a flag in 2021, removed it completely in Chrome 110 (February 2023), then brought it back behind a flag in Chrome 145 (February 2026). caniuse now lists Chrome 155 and Firefox 158 as the first versions with JPEG XL switched on by default, but neither had reached the stable channel when we checked. Safari has shown JPEG XL images since Safari 17, without progressive loading or animation, which is why caniuse marks it as partial.

So JPEG XL is close, but not there. Until those releases ship and people have updated, treat it as an optional extra, never the only file you serve.

How we tested

We used three homepage screenshots from our portfolio, all saved as lossless PNGs at 1280 by 800 pixels:

• Stag Hen Houses: a full-width photo of a pool and garden, with a headline over it (1,348 KB as PNG).
• Joe's Fencing: a full-width photo of a fence and houses, with a headline over it (1,167 KB as PNG).
• UK Name Change: a flat interface with text, gradients and pricing cards (394 KB as PNG).

Comparing formats at the same quality number is misleading, because "quality 80" means something different in every encoder (we show why below). Instead we scored every file with SSIMULACRA2, a perceptual metric from Cloudinary that rates how close a compressed image looks to the original. Its authors describe 70 as high quality (artefacts visible but not annoying), 85 as excellent and 90 as visually lossless. For each image and format we searched for the smallest file that matched the score of a normal JPEG at quality 80, then for the smallest file that reached 85.

Test set-up: Apple M5 Mac, macOS 26.4.1, Python 3.12. Encoders: libjpeg-turbo 3.1.4.1 (optimised, progressive), libwebp 1.6.0 (method 4) and libavif 1.4.2 with aom 3.14.1 (speed 6), all through Pillow 12.3.0, plus libjxl 0.12.0 (effort 7) through imagecodecs 2026.8.16. Everything ran on a single thread and times are the median of 7 runs. Scores use the ssimulacra2 0.3.0 Python package. mozjpeg wasn't available, so our JPEG baseline is slightly larger than a mozjpeg file would be.

Results: file size at the same visual quality

How small can each format go while looking as good as a standard JPEG at quality 80?

To hit those scores, WebP needed quality 88, 85 and 68, AVIF needed quality 66, 63 and 49, and JPEG XL needed a distance of about 2.3, 2.0 and 5.3.

At a higher bar, a SSIMULACRA2 score of 85, the picture changes:

*WebP topped out at a score of 83.8 on this image even at quality 100, so it never reached the target.

Three things stand out:

• AVIF was the smallest at everyday web quality on all three images.
• WebP struggles with photos. The often-quoted "25% to 35% smaller than JPEG" held on neither photo, both full of fine texture (foliage, fence boards, water). On the flat interface it was excellent.
• JPEG XL shines at high quality. At a score of 85 it produced the smallest file on both photos, 23% to 49% smaller than AVIF, while AVIF needed near-maximum settings to get there.

Why "quality 80" isn't quality 80

Most online comparisons encode every format at a popular setting and compare the file sizes. We ran those settings too, and the files are nowhere near equal quality. JPEG XL at distance 1.0 produced 189 KB for both photos, larger than the JPEG, but it scored 84 to 86 against the JPEG's 72 to 75. AVIF at quality 50 produced the smallest files (52 KB and 60 KB) but scored only 61 to 65, visibly softer than the JPEG.

That is why articles disagree so much about which format "wins". If you run your own tests, compare at equal quality, or at least look at the images side by side at 100% zoom.

Encode and decode speed

Timings per 1280 by 800 image on one CPU thread, at the settings from the first results table:

AVIF took 29 to 46 times longer to encode than JPEG, and slowed further at high quality (530 ms at quality 98). That is fine for a single upload, but if you generate several sizes of thousands of product images, run the conversion in a background queue. Decoding was quick for every format.

WebP vs JPEG XL

On compression alone, JPEG XL beats WebP. On our photos it matched JPEG quality at 96 KB and 115 KB against WebP's 156 KB and 134 KB, and the gap widened at high quality. On the flat interface they were level at web quality (49 KB against 50 KB). JPEG XL also brings features WebP lacks: lossless recompression of existing JPEGs, progressive loading and HDR.

The catch is support. WebP works for about 97% of web users, while JPEG XL works fully in none of the major browsers by default. WebP is the practical choice today, and JPEG XL is the one to watch.

AVIF vs JPEG XL

For typical website images, AVIF wins today: it produced the smallest files at everyday quality on all three test images and has near-universal support. JPEG XL is the better format for high-fidelity photography. At a score of 85 it beat AVIF on both photos and encoded faster, and it can recompress JPEGs losslessly, which AVIF can't. If fine detail matters to your business, offer JPEG XL first and AVIF second.

AVIF vs JPEG: is AVIF better?

For delivering images on the web, yes. AVIF was 37% to 67% smaller than JPEG at the same visual quality in our tests, and browsers used by about 95% of people support it. JPEG remains the universal fallback, and it is what email clients and older software expect. Keep a JPEG as the <img> fallback, and keep your high-resolution masters so you can re-encode them as formats improve.

Does JPEG XL support transparency?

Yes. JPEG XL supports an alpha channel in both lossless and lossy modes. We tested it with our own logo, a 314 by 240 pixel PNG in which 74% of the pixels are transparent:

All four formats kept the transparency. JPEG XL lossless was the smallest pixel-perfect option, and for a flat logo its lossless mode even beat its lossy mode. AVIF was tiny but softened the transparent edges slightly. If you have the logo as vector artwork, SVG beats all of them.

Converting JXL to AVIF, and JPEG to JXL

There is no lossless route from JPEG XL to AVIF. You decode the JXL file to pixels and encode those pixels as AVIF, which adds a second round of compression, so always convert from the highest-quality source you have. With the command-line tools from libjxl and libavif:

djxl photo.jxl photo.png
avifenc -q 60 -s 6 photo.png photo.avif

Or in Python, using Pillow 11.3 or later (which reads and writes AVIF natively) and imagecodecs for the JPEG XL decode:

import imagecodecs
from PIL import Image

with open("photo.jxl", "rb") as f:
    pixels = imagecodecs.jpegxl_decode(f.read())

Image.fromarray(pixels).save("photo.avif", quality=60)

Going the other way is where JPEG XL is unique. cjxl photo.jpg photo.jxl recompresses an existing JPEG with no loss at all, and djxl photo.jxl photo.jpg gives you back the original file byte for byte. On our three JPEGs this saved 11%, 11% and 17%, and we confirmed that each original came back identical. That is less than the figure of about 20% usually quoted, probably because our JPEGs were already optimised, but it is a free saving for an archive of existing photos.

How to serve modern formats today

Let the browser choose. It uses the first <source> it supports and falls back to the <img>:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Describe what the image shows"
       width="1280" height="800">
</picture>

For a photography site, add <source srcset="hero.jxl" type="image/jxl"> above the AVIF line. Always set width and height so the layout doesn't jump, and use loading="lazy" below the fold but never on the hero image (our guide to lazy loading images explains why). These details matter as much as the format for Core Web Vitals, and they are part of the technical SEO and site-speed work we do for clients.

On a Django site you can generate the AVIF, WebP and JPEG versions automatically when an image is uploaded, for example in a background task, so nobody has to export three files by hand.

Our recommendations

• Product photos and hero images: AVIF at around quality 60 to 65 (the level that matched a quality 80 JPEG in our tests), with a WebP or JPEG fallback. If you sell online, this is one of the easiest speed wins on a custom e-commerce build.
• Screenshots, illustrations and flat graphics: AVIF first. WebP is also very good here, at roughly half the size of JPEG.
• Logos and icons: SVG where you can. Otherwise lossless WebP, or lossless JPEG XL as an extra source.
• Photography portfolios and high-detail work: offer JPEG XL first, then AVIF, then JPEG.
• Archives of existing JPEGs: recompress them to JPEG XL losslessly. You save 10% to 20% with zero quality loss, and you can always get the originals back.

If your pages are slow and you think images are to blame, book a free call and we'll look at your site with you.