WebP vs AVIF for websites: size, quality and support

For a website, AVIF usually gives the smaller file at the same visual quality, while WebP encodes faster, renders progressively and reaches a slightly wider set of browsers. Both work in every current major browser, so the practical answer is to serve AVIF first, WebP second and JPEG or PNG last, from one <picture> element or an image CDN.

The format is the second decision, though. An image four times wider than the slot it sits in stays slow in any format, so size first and convert second.

How do WebP and AVIF compare?

AVIF wins on compression and loses on encode time and progressive rendering. WebP is the steadier all-rounder: fast to encode, supported for years, and still far smaller than JPEG or PNG. The table puts the measured and documented differences side by side, each from the format's own documentation or a browser vendor.

MDN's summary matches the table: it calls WebP an "excellent choice" and says AVIF "offers slightly better compression, but is not quite as well-supported in browsers and does not support progressive rendering."

Which is better for image quality: WebP or AVIF?

AVIF usually reaches the same visual quality in fewer bytes, and it supports higher color depths than JPEG or PNG, according to MDN. WebP is close behind: MDN calls AVIF's compression only "slightly better". The gap depends on the image, so compare your own hero image at matched quality rather than trusting a single percentage.

Two quality settings are worth knowing before you compare, because the numbers do not mean the same thing across encoders:

• cwebp takes -q from 0 to 100 with a default of 75.
• sharp defaults to quality 80 for webp() and 50 for avif(), with an effort option (0 to 6 for WebP, 0 to 9 for AVIF, default 4) that trades encode time for size.

So "quality 50" in AVIF is not a lower bar than "quality 80" in WebP; the scales differ. Judge by eye at the size the image will be displayed, then compare bytes. web.dev points to Squoosh (squoosh.app), which runs the AVIF encoder in the browser, for quick comparisons.

Is AVIF supported in all browsers?

Yes, in all current major browsers: Chrome 85 and later, Firefox 93 and later, Edge 121 and later, and Safari with full support from 16.4 on macOS and 16.0 on iOS. What it lacks is historical depth. Visitors on older Safari or Edge versions need a fallback, and MDN recommends providing one in WebP, JPEG or PNG.

WebP has the longer history: Chrome since 32, Firefox since 65, Edge since 18 and full Safari support since 16.0 on macOS. caniuse put full support at about 97% of global usage for WebP and about 95% for AVIF in September 2026. Those gaps are small, but they are real visitors, and a fallback costs you one extra <source> line.

How do you serve both with a picture element?

List the formats from smallest to most compatible inside <picture>. The browser takes the first <source> whose type it supports and ignores the rest, and the <img> inside is both the fallback and the element that carries alt, width, height and loading hints.

<picture>
  <source type="image/avif"
          srcset="hero-800.avif 800w, hero-1600.avif 1600w"
          sizes="(max-width: 800px) 100vw, 800px">
  <source type="image/webp"
          srcset="hero-800.webp 800w, hero-1600.webp 1600w"
          sizes="(max-width: 800px) 100vw, 800px">
  <img src="hero-800.jpg"
       srcset="hero-800.jpg 800w, hero-1600.jpg 1600w"
       sizes="(max-width: 800px) 100vw, 800px"
       width="800" height="450"
       alt="Dashboard showing this week's signups by channel"
       fetchpriority="high">
</picture>

Steps to produce the files:

1. Export the master image at the largest width you will ever display, then resize to each width in your srcset (here 800 and 1,600 pixels).
2. Encode each width to AVIF, for example with avifenc --min 0 --max 63 -a end-usage=q -a cq-level=18 -a tune=ssim hero-800.png hero-800.avif, the settings web.dev suggests as a starting point.
3. Encode each width to WebP, for example cwebp -q 75 hero-800.png -o hero-800.webp.
4. Keep a JPEG (or PNG for flat graphics and transparency) at each width for the <img> fallback.
5. Compare the three files per width. If the AVIF is not smaller than the WebP for a given image, drop the AVIF source for that image.

Keep width and height on the <img> so the browser reserves space before the image arrives. The alt text rules are the same whatever the format; the alt text best practices cover what to write.

How do you set WebP and AVIF in Next.js?

Set images.formats in next.config.js. The default is ['image/webp']. To add AVIF, put it first, because Next.js reads the request's Accept header and serves the first format in the array that matches, falling back to the source image's format when nothing matches or the image is animated.

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

The Next.js docs attach four caveats to that setting:

• They still recommend WebP for most use cases.
• AVIF takes about 50% longer to encode, so the first request for each image size is slower; cached requests after that are faster.
• Each format is cached separately, so storing both roughly doubles optimized-image storage.
• If you self-host behind a proxy or CDN, it must forward the Accept header, or every visitor gets the same format.

next/image also generates the srcset for you from deviceSizes (default [640, 750, 828, 1080, 1200, 1920, 2048, 3840]) and imageSizes, provided you pass a sizes prop that describes how wide the image renders.

Can the server pick the format instead of a picture element?

Yes. The browser sends an Accept header listing the image types it can decode with every image request, and a server, image CDN or next/image can read it and return AVIF, WebP or JPEG from a single URL. The one rule that makes this safe is caching: the response must say which header decided it.

That is what the Vary header is for. MDN explains that a cache needs to know which request headers the server used to choose the content, so it can replay that choice and serve an acceptable variant without asking the server again. Send Vary: Accept on every negotiated image. Without it, a shared cache can store the AVIF answer and hand it to an older browser that asked for WebP, and that visitor sees a broken image.

Check it on a live image with curl -sI -H "Accept: image/avif,image/webp,*/*" https://yoursite.com/hero.jpg, then repeat with -H "Accept: image/webp,*/*". The Content-Type should change between the two requests, and both responses should carry Vary: Accept.

Why doesn't a new format fix an oversized image?

Because the format changes bytes per pixel, not the number of pixels. A 4,000 pixel wide photo in a 400 pixel slot sends about 100 times the pixels the slot can show (ten times the width, ten times the height), and even a 50% format saving leaves it far heavier than a correctly sized JPEG.

Lighthouse checks this directly. It compares each image's rendered size with its actual size and fails the image when the rendered size is at least 4 KiB smaller. In Lighthouse 13 that audit, the modern image formats audit and the image optimization audit were merged into one image delivery insight, so format and sizing now appear together.

The order of work that pays off:

1. Size each image to its largest displayed width, and use srcset with sizes for responsive layouts.
2. Load the largest above-the-fold image eagerly with fetchpriority="high" and never with loading="lazy".
3. Lazy-load images below the fold.
4. Then convert to AVIF and WebP.

When the hero image is the Largest Contentful Paint element, these steps come first; the guide to improving Largest Contentful Paint shows how to confirm which element it is. If Search Console already shows a failing URL group, the Core Web Vitals assessment failed guide explains how the field data behind it is collected.

Which format should you choose?

Serve AVIF with a WebP fallback for photos and large hero images, where AVIF's size advantage is largest and the image is encoded once and cached. Use WebP alone when encode time matters, such as user uploads converted on the fly, or when you can only store one format.

Google Search lists both WebP and AVIF among the formats it supports for images, so the choice is about speed and your build pipeline rather than eligibility.

To see which images on a live page are too heavy, run the free scan on LaunchScaler. It needs only your URL and no account, and its speed checks flag legacy JPEG and PNG files that would be meaningfully smaller as AVIF or WebP, images delivered far above their display size, a lazy-loaded LCP image and images rendered without reserved dimensions, among 156 checks across 6 of its 7 categories.