WebP vs AVIF: Which Image Format to Use in 2026

The WebP vs AVIF question is not the decision that matters most: in 2026 both formats clear 96% browser support and their real-world difference in production is smaller than benchmarks promise. What actually moves the needle is serving the right file at the right size.

This article follows that order: weight first, where the savings live; then the formats, with their numbers and their costs; and finally delivery, where a good part of what you just won gets lost. Image indexing is covered in our Google Images guide; here the subject is kilobytes.

Image Weight Is Your Biggest Lever

Of everything a page downloads, images are almost always the heaviest block and the easiest to trim: they do not break the layout and they do not depend on third parties.

The Real Numbers

The Media chapter of the Web Almanac 2024 measures what is actually served on mobile: JPEG 32.4%, PNG 28.4%, GIF 16.8%, WebP 12% and AVIF just 1.0%. JPEG lost 8 points since 2022 and AVIF grew about 386% relative in two years, but the practical reading is that most of the web still ships formats from the nineties.

The Heaviest Image: 135 KB at the Median

On a typical mobile page the largest image weighs 135 KB at the median and 1,002 KB at the 90th percentile, while the median of all images is only 12 KB. This is not an image problem in general: it is two or three images, almost always the hero or the product photo. The Network panel sorted by size and Lighthouse's "Properly size images" audit give you the list in minutes.

Bits per Pixel: The Only Fair Comparison

Any format can be compressed until it looks bad, so comparing raw file sizes is a trap. The honest metric is bits per pixel at comparable quality: GIF 6.7, PNG 3.8, JPEG 2.0, AVIF 1.4 and WebP 1.3 on real sites. That last pair is the uncomfortable detail: AVIF only reaches 1.4 because current encoders prioritize quality.

WebP, AVIF, JPEG, and PNG: What Each One Does

Three questions decide almost everything: photography or illustration, transparency, and how much you can spend encoding. Our general image optimization guide covers the basics; here we go one level deeper.

JPEG and PNG: When They Are Still Right

JPEG remains reasonable for photography when the pipeline cannot generate variants, and for the fallback src of any <picture>. PNG survives on hard-edged transparency and screenshots with text: with flat areas, a well-exported PNG can weigh less than an over-compressed WebP.

WebP: The Safe Bet

web.dev documents 25-35% reductions against JPEG and up to 80% against PNG: Facebook saved those percentages and YouTube got 10% faster loads with WebP thumbnails. It has 97.08% global support and encodes fast. If your internal docs still say "WebP isn't supported in every browser yet", that note expired.

AVIF: More Compression at a Cost

AVIF is built on the AV1 codec: web.dev describes better perceptual quality at smaller file sizes than JPEG or WebP, and support is now 96.33% globally (Chrome and Opera 2020, Firefox 2021, Safari 2022). The cost is real: encoding is slow, decoding burns CPU on old phones, and a browser without support discards the image without rendering anything. Never ship it as your only src.

WebP vs AVIF: How to Decide by Image Type

Photography vs Illustration and Text

On photography with smooth gradients AVIF wins consistently. On flat illustrations, logos and screenshots with small text the advantage shrinks: both handle flat areas well, and sharp text punishes them equally. For product photos compare AVIF and WebP; for interface screenshots compare all three.

Transparency, Animation, and Visible Quality

Both support transparency and animation, so a 4 MB animated GIF has no excuse left. Where compression shows is in texture: faces, fabric, skies with gradients. There AVIF holds up better and WebP starts to band. If your image has a large face, that is the criterion, not the savings percentage.

The Cost Nobody Measures: Encoding and Pipeline

Generating AVIF costs several times more CPU than WebP. If you publish twenty images a day and encode on the fly, it shows up in the bill and in upload times: better to encode once at upload. Watch storage too, because every format and every width multiplies files; if volume grows, a CDN that transforms images at the edge can be cheaper.

How to Serve AVIF and WebP (and JPEG to the Rest)

picture With type: Order Decides

The browser walks the <source> elements in order and takes the first one it understands: newest first, fallback last.

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w" sizes="100vw">
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w" sizes="100vw">
  <img src="hero-800.jpg" alt="Specific description" width="1600" height="900">
</picture>

Reverse the order and you serve JPEG to everyone, which makes the AVIF encoding effort pointless.

The img src Is Not Decorative

Google Search Central accepts BMP, GIF, JPEG, PNG, WebP, SVG and AVIF in the src, and recommends <picture> and srcset, but reminds you that some crawlers do not parse them: the src must be a real, reachable image. And the old fear "does Google read AVIF?" is settled: yes.

srcset and sizes: Where the Savings Get Lost

w vs x Descriptors

With w you declare each file's real width and the browser picks what it needs, but to do that it must know how much space the image occupies in the layout: that is sizes. With x you declare pixel densities and it assumes the CSS size. The Almanac measures 62-64% usage of w against 15% for x, with srcset on 42% of mobile pages.

The Uncomfortable 180 KB Wasted

The median sizes value is 16% too large on mobile and 43% on desktop. One in five desktop sizes is so inaccurate that the browser picks a worse resource, and 25% of pages using w load 180 KB or more of wasted image. An image inside a 300-pixel column with sizes="100vw" makes the browser download the 1600 variant. RespImageLint flags them.

sizes="auto" and Its Real Support

sizes="auto" lets the browser use the width it already computed and is ideal with loading="lazy". Support is 74.64%: Chrome and Edge 126 or higher, Firefox 150 or higher and Safari 27 only partially. As progressive enhancement it works; as the foundation of a whole site, not yet.

The Hero Image: Where Load Order Decides LCP

Never Lazy-Load the Hero

web.dev is blunt: never lazy-load your LCP image. Adding lazy to the hero delays its discovery and always hurts LCP; lazy belongs below the fold. Which element is your LCP is explained in our LCP guide, and the detail in our lazy loading guide.

fetchpriority, preload, and Dimensions

If the main image is in the HTML, fetchpriority="high" is enough; if it is only referenced from CSS or JavaScript, move it earlier with <link rel="preload" as="image" fetchpriority="high" type="image/webp" href="/hero.webp">. Marking more than one or two images as high priority cancels the effect. And declare width and height: without them the browser reserves no space and the image pushes content down, which is CLS.

A Checklist to Shrink Your Images This Week

From Inventory to a Measured Before and After

Sort Network by size and note the three heaviest images.
Compare real width against displayed width (x2 on dense screens).
Resize: 1600 pixels covers almost any hero.
Encode WebP as the base and AVIF for large photos.
Add srcset with three to five widths and compute sizes from the real layout.
Remove lazy from the hero and add fetchpriority="high".
Measure again and record the before and after in kilobytes.

Four Mistakes Costlier Than the Format

One: serving 4000 pixels for an 800-pixel slot, which multiplies weight by twenty-five. Two: recompressing an already compressed JPEG, which adds artifacts and kilobytes. Three: still shipping animated GIFs, the most expensive format per pixel. Four: ignoring pixel density and serving a single resolution.

Switching formats without fixing dimensions and delivery is switching problems. Do it in this order and the savings show up in page weight, not in a promised ranking. To measure the real effect, field data rules: that is the difference we explain in PageSpeed Insights and its two kinds of data.