WebP vs AVIF vs JPEG: we measured all three on 12 web images

Every article on WebP vs AVIF says AVIF is smaller. Ours does too, mostly.

We encoded 12 typical web images, from photorealistic scenes to 3D renders to page screenshots, as JPEG, WebP and AVIF, matched them to the same visual quality and measured the bytes, the encode time and the decode time in Chrome. AVIF came out a median 20% smaller than WebP, and JPEG needed a median 37% more bytes than WebP. But on the three grainiest images AVIF needed more bytes than WebP, at the settings most tools use it took 7.6 times as long to encode, and on our own server that cost is why our site still serves WebP.

TL;DR

• Size: at the quality of WebP q85, AVIF was a median 20% smaller than WebP; JPEG was a median 37% larger.
• Grain: on the three noisiest images, AVIF was 17–22% larger than WebP.
• Encode: AVIF took a median 7.6× as long as WebP with sharp's defaults (1.8× at the effort Next.js uses).
• Decode: practically a tie, AVIF a median 3% slower in Chrome.
• Rule: AVIF where images are encoded once, ahead of time; WebP where a server encodes them on demand.

The three formats in one paragraph

JPEG is the format every browser and every tool has read for decades. WebP is Google's format, built on the VP8 video codec. AVIF is the image format of AV1, the video codec of the Alliance for Open Media. All three compress photos with loss; WebP and AVIF can also do lossless images, transparency and animation. The question for a website is which one gives the smallest file at the quality you would publish, what it costs to make, and whether every visitor can see it.

How we measured

We picked 12 images of the kinds that end up on business websites: two photorealistic scenes, one clinic website with a portrait photo, six 3D renders from our own article art and three screenshots of pages on our site. Every source was a lossless PNG resized to 1,600 px wide. We encoded each one with sharp, the image library behind Next.js and many other tools, as JPEG (mozjpeg) at eight quality settings from 50 to 95, WebP at the same eight, and AVIF at eleven from 30 to 80, with sharp's defaults otherwise.

To compare at equal quality we measured SSIM, a standard similarity score, between each file and its source, and for each image took the score WebP reached at quality 85, the setting our site uses. We then read off how many bytes JPEG and AVIF needed to reach the same score.

Encode times are wall-clock on an Intel Core i7-6700K. Decode times were measured in Chrome 142 with createImageBitmap, 12 rounds per file in rotating order after a warm-up round. None of our sources is a straight-from-camera photo; the photorealistic scenes are renders, which is why the image types are reported separately.

The results

File size of each image at the quality of WebP q85:

Each image 1,600 px wide, encoded with sharp 0.35.5 (mozjpeg, libwebp 1.6.0, libaom 3.15.1) on 10 October 2026. JPEG and AVIF were interpolated to the SSIM that WebP reached at quality 85, so every row compares files that look equally good by that measure; the q in brackets is the setting that gets there. "Not reached": JPEG stayed below that quality even at q95.

File size at the same quality

At the quality we serve, AVIF was a median 20% smaller than WebP, and JPEG was a median 37% larger than WebP. The AVIF advantage was largest on screenshots (a median 30%) and on the simple, clean render of a figure in a hospital bed, which came out at half the size. On the photorealistic scenes it was 19 to 33%. JPEG was the largest file wherever it could reach WebP's quality at all; on the screenshots and the grainy renders it could not, even at quality 95.

At a lower quality the gap widens. Matched to WebP at quality 75, the default of Next.js, AVIF was a median 27% smaller and JPEG a median 56% larger. Compared with the lossless PNG sources, the WebP files were about a twelfth of the size: 2.2 MB against 26 MB for all 12 images together.

Where AVIF loses: grain and fine noise

On three images AVIF needed more bytes than WebP, not fewer: 17% more on two of them and 22% more on the third. All three are renders with visible film grain, and they are the three noisiest images in the set by a simple measure of pixel-to-pixel detail, between 24 and 28 against 2 to 16 for the other nine. AVIF tends to smooth that kind of fine noise away, and keeping it costs bits.

Because those three are also among the largest files, the 12 AVIF files together came out 1% larger than the 12 WebP files; without them, AVIF saved 24% in total.

So if your images are grainy photos or renders with deliberate texture, test them before switching. If they are clean product shots, illustrations or screenshots, AVIF will almost certainly be smaller.

Encoding: where AVIF's cost is paid

With sharp's default settings, AVIF took a median 7.6 times as long to encode as WebP: about a second per image here, against 0.15 seconds for WebP and 0.13 for JPEG. The ratio ranged from 3 to 15 times, and the slowest were the large, detailed images. Next.js encodes AVIF at a lower effort setting, effort 3 instead of sharp's default 4; at effort 3, AVIF took 1.8 times as long as WebP, and the files were a median 4% larger at the same quality setting.

AVIF's cost is paid when the image is encoded, so whether it matters depends on where that happens. In a build step or a CDN that encodes each image once and caches it, a second per image is nothing. On a server that encodes on the first request, the first visitor waits for it.

We measured that on our own hosting before deciding: a 24-megapixel portfolio image took 40.07 seconds as AVIF against 2.57 seconds as WebP through the same Next.js optimiser, to save 17% of the bytes, and it kept one CPU busy the whole time. Our site serves WebP for that reason.

Decoding in the browser: practically a tie

Decoding took about the same time for AVIF and WebP: AVIF was a median 3% slower, around 14 milliseconds for a 1,600-pixel image on a desktop, and JPEG was 20% faster than WebP. Slowing the CPU down fourfold in Chrome changed almost nothing, because Chrome decodes images off the main thread.

The download is what counts. At the 1.6 Mbps that Lighthouse uses to simulate a mobile connection, the median AVIF file arrived 69 milliseconds sooner than its WebP version, and the smaller photorealistic scene 128 milliseconds sooner. That is the difference that shows up in Largest Contentful Paint when the image is the largest element on the page.

Browser support in 2026

Both formats are safe for almost every visitor. Can I Use puts global support at 96.74% for WebP and 95.35% for AVIF. AVIF has worked in Chrome since version 85, Firefox since 93, Safari on iPhone since iOS 16 and Edge since 121; Safari on the Mac lists it as partial, because it needs macOS Ventura or later and does not support AVIF's noise synthesis.

The few browsers left without either are the reason a fallback still makes sense: a picture element that offers AVIF first, then WebP, then JPEG:

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

Or an image service that picks the format from what the browser says it accepts. In Next.js that is the built-in optimiser, which serves WebP only by default; AVIF is opt-in:

// next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
  },
}

Read the encoding section before you add that line if your optimiser runs on the same box as your app.

Which format to use

Use AVIF where images are encoded once, ahead of time, and WebP where a server encodes them on demand. A static site, a build pipeline or an image CDN can afford AVIF's encoding time and gets files a fifth smaller for it, with WebP as the fallback. A self-hosted optimiser on modest hardware, like ours, is better off with WebP, which is already about a quarter smaller than JPEG. Keep JPEG as the last fallback only.

Whatever you choose, it matters less than serving images at the right size: a 1,600-pixel image where 800 would do costs more than any format change saves.

Quality settings that match

The matches in our test were:

In sharp, that is:

import sharp from 'sharp'

await sharp('in.png').resize({ width: 1600 }).webp({ quality: 85 }).toFile('out.webp')
await sharp('in.png').resize({ width: 1600 }).avif({ quality: 67 }).toFile('out.avif')

Lower AVIF numbers do not mean worse images than the same number in WebP: the scales are different. One trap: Next.js turns its quality setting into an AVIF quality by multiplying it by 0.625, so 85 becomes 53. By our measure that is noticeably below its WebP at 85, so part of the saving you see from switching on AVIF in Next.js is lower quality.

Images and web fonts are the two parts of page weight a designer decides most directly.

Originally published on levelui.com, with the full source list. Also available in German and Romanian.

We are Level UI, a web design and development agency in Bucharest.