AVIF vs WebP: which is smaller, and when

What AVIF and WebP are

WebP is Google's image format, announced in 2010. Its lossy mode compresses a picture the way the VP8 video codec compresses a single frame; a separate lossless mode, VP8L, is built for graphics with sharp edges and few colours. Both modes can carry transparency, and animated WebP can stand in for GIF.

AVIF (AV1 Image File Format) stores a frame compressed with AV1, the royalty-free video codec of the Alliance for Open Media, inside a HEIF container. Its 1.0 specification appeared in 2019. AV1's coding tools are a decade newer than VP8's, so AVIF keeps more detail per byte on photographs, and it adds 10- and 12-bit colour and HDR. The price is encoding time: producing an AVIF takes noticeably more CPU than a WebP of the same picture, which is why image services convert once and cache the result.

Browser support has stopped being the deciding question. According to caniuse.com (data of 30 September 2026), about 97% of browsers in use display WebP and about 95% display AVIF. WebP works since Chrome 32, Firefox 65 and Safari 14 (on macOS 11 or later); AVIF since Chrome 85, Firefox 93, Safari on iOS 16, Safari 16.4 on the Mac (still images from Safari 16.1, on macOS 13 Ventura or later) and Edge 121. The few percent left over are why a fallback still matters, and with server-side negotiation that fallback costs nothing.

Which is smaller? It depends on the image

Most comparisons quote one number, "WebP is 30% smaller" or "AVIF halves your images", averaged over photographs. A real site also serves screenshots, logos and icons, and there the ranking can flip. On 5 October 2026 we ran four images through the image optimizer behind CDN.com.tr, at its production settings, and counted the bytes each format produced.

News photo, JPEG, 1920×1080. Original 262,025 bytes; optimized JPEG 186,137; WebP 113,860; AVIF 86,936. The textbook case: WebP is 39% smaller than the optimized JPEG, and AVIF another 24% smaller than WebP, a third of the original's bytes.

News photo, JPEG, 926×594. Original 131,472 bytes; optimized JPEG 93,348; WebP 89,360; AVIF 77,452. The same kind of picture, smaller and already well compressed: WebP saves only 4% over the JPEG, AVIF 17%.

Panel screenshot, PNG, 1156×775. Original 105,078 bytes; optimized PNG (pngquant and optipng) 40,379; WebP 41,218; AVIF 27,942. Flat colours and text are what a palette PNG does best: WebP came out 839 bytes larger than the PNG, while AVIF was still 31% smaller than it.

Favicon, PNG, 16×16. Original 701 bytes; optimized PNG 483; WebP 314; AVIF 682. At this size the container decides: 429 of the AVIF's 682 bytes are HEIF boxes that describe the image before a single pixel, while the WebP's wrapper is 46 bytes. AVIF ended up 41% larger than the PNG, and WebP was the smallest.

The pattern is what transfers. AVIF wins clearly on photographs and detailed screenshots; WebP is a safe second; on flat graphics a well-optimized PNG can beat WebP, and on tiny icons AVIF's fixed overhead outweighs its better compression. Exact bytes depend on the encoder and its settings, so read these as one service's measurement, not a law. No percentage holds for every image: the reliable test is to encode the image and compare bytes.

How a server picks the format

Every image request carries an Accept header listing the formats the browser can display. Chrome sends image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8; a browser without AVIF support leaves image/avif out. A server or CDN that converts images reads this list and answers the same URL with AVIF, WebP or the original. The file name does not change, so hero.png may arrive as AVIF: the Content-Type header, not the extension, says what was sent.

Because one URL now has several possible answers, the response must carry Vary: Accept. It tells every cache on the way, from the CDN to a company proxy to the browser, to keep a separate copy per Accept value. Without it, a shared cache can hand the AVIF one visitor received to the next visitor, whose browser cannot show it.

The other approach moves the choice into the HTML. A <picture> element lists <source> files with type="image/avif" and type="image/webp", the browser takes the first type it supports, and the <img> inside is the fallback. It needs no server logic and no Vary, at the cost of producing and storing every variant yourself and keeping the markup in step. Either way, checking what a browser really gets takes three requests.

One image, three Accept headers: compare what comes back

# a browser that accepts AVIF and WebP
curl -so /dev/null -w '%{content_type} %{size_download} bytes\n' \
  -H 'Accept: image/avif,image/webp,*/*' https://example.com/hero.png

# a browser with WebP only
curl -so /dev/null -w '%{content_type} %{size_download} bytes\n' \
  -H 'Accept: image/webp,*/*' https://example.com/hero.png

# a client that asks for nothing in particular
curl -so /dev/null -w '%{content_type} %{size_download} bytes\n' \
  -H 'Accept: */*' https://example.com/hero.png

# the header that keeps shared caches honest (a GET, not HEAD)
curl -s -D - -o /dev/null -H 'Accept: image/avif,*/*' \
  https://example.com/hero.png | grep -i '^vary'

Check what your site serves

The checker below runs those requests for a whole page. It reads the page's HTML, takes up to 20 images from <img>, srcset, <picture> and og:image, and requests each one twice: once as a current browser asks (Accept: image/avif,image/webp,…) and once as a client that accepts anything (Accept: */*). It reads the first bytes of every answer to tell the real format, whatever the file name says, counts the bytes, and reports Vary and the cache status. A single image address works too.

Requests come from our server in Turkey, so a CDN may answer from a different location than it does for your visitors. Images that JavaScript adds after the page loads, and CSS backgrounds, are not in the HTML and are not checked. The checker's own page lists every limit.

Reading the results

AVIF or WebP. A browser that asked for modern formats received one. The size beside it is what that browser downloaded; the "Other browsers" column is what every browser without AVIF or WebP support gets. The savings line adds up only images whose two answers were both read in full and came in different formats: it is a measurement, never an estimate.

Original only. Even a browser that asked for AVIF and WebP received JPEG, PNG or GIF, so nothing on the way converts the image. If some images arrive as AVIF and others only in their original format, look at what the second group has in common: another host, a path no rule covers, an extension the converter skips.

Same file for every browser. Both requests received the same format. That is the result for a site without negotiation, and also for a site that already serves .webp files to everyone: every current browser displays them, but AVIF's extra saving stays unused. With nothing to compare, no saving is shown.

Without Vary: Accept. The answer changes with Accept but does not say so, and shared caches may store it. Fix this one first: it is the only result on the list that can show a visitor a broken image.

Rate-limited or blocked. Some sites answer automated requests with 429, 403, a bot check or a small 503 page. The checker then stops requesting that host for the rest of the check and marks the remaining images as not checked. That says something about the site's protection, not about its images: try again a few minutes later, or check one image address directly.

A sensible strategy: AVIF, then WebP, never larger

Put together, the strategy most sites want is short. Offer AVIF first: on photographs and detailed screenshots it is the smallest by a clear margin. Keep WebP as the second choice for browsers without AVIF. Keep the original as the last fallback, so every browser gets an image it can show.

Then add the rule our favicon taught us: compare bytes image by image, and never send a converted file that is larger than the one you would otherwise send. A format is a means; fewer bytes are the goal. A pipeline that converts blindly makes some share of your images heavier and still reports them as optimized.

Two practical notes. Convert once and cache the result, at a CDN edge or in a build step, rather than on every request: AVIF encoding is the expensive part. And keep logos and icons that are drawn rather than photographed as SVG where you can: there is nothing to convert, and they stay sharp on every screen.

AVIF and WebP on CDN.com.tr

Image optimization is a switch in the panel, for the whole account or for a single delivery rule. With it on, the edge serves JPEG and PNG images as WebP to browsers that support it; our image service converts each image once and the edge caches the result. For the account you can also choose WebP + AVIF: browsers that accept AVIF then receive AVIF, other modern browsers WebP, and the rest the image in its original format, all from the same URL, with Vary: Accept and a separate cache copy per format.

Processing counts toward your monthly quota, AVIF at a higher rate than WebP because it takes more CPU; the panel shows the rate next to the switch. Run the checker above on your own pages to see, image by image, which format each browser receives and how many bytes it takes.