AVIF vs WebP on 27 homepages: 269 WebP images, 23 AVIF, and 116 with no src at all

FIELD TEST · 2026-08-28 · 27 homepages · single crawl · 1,675 img elements parsed

Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-28 at 11:37 (+0800) with a browser user agent and no JavaScript execution. Every <img> and every <source> inside a <picture> was recorded, and the file extension was read from the src URL after stripping the search string.

The avif vs webp comparison is settled in the compression numbers and nowhere near settled on real homepages. Across 1,675 image elements on 27 sites, 269 point at a .webp file and 23 point at an .avif one — and all 23 sit on two sites. The bigger surprise is further down: 116 <img> elements carry no src value at all.

How we measured it

One HTTP request per site, no rendering, no retries, no image requests. The inclusion rule was fixed before the run: final status 200, decoded body of at least 10,000 bytes, body containing <body. stackoverflow.com and medium.com returned 403 and www.reddit.com returned an 8,393-byte shell, leaving 27 sites.

Format here means the extension written in the URL, not the bytes a server would return. Each <img> was sorted into exactly one of four buckets: no src value, a data: URI, a URL with no file extension, or a URL ending in one. The four buckets add to 1,675.

What avif vs webp looks like in delivered HTML

WebP is on nine of 27 sites. AVIF is on two.

The two AVIF sites are webflow.com with 22 images and www.cloudflare.com with one. Both also ship WebP or PNG alongside it. Nothing in this panel uses a format outside the list Google publishes: Google Images best practices, retrieved 2026-08-28, says Google Search supports images referenced in the src attribute of img in BMP, GIF, JPEG, PNG, WebP, SVG and AVIF. BMP is the only one of those seven that appears zero times here.

MDN's image format guide, retrieved the same day, is where the ranking comes from: lossy AVIF images are "around 50% smaller than JPEG images", and AVIF generally compresses better than WebP — "median 50% vs. 30% compression for the same JPG set", a figure MDN attributes to CTRL Blog. A 12-to-1 deployment gap in the other direction is not what those numbers predict.

The 116 images with no src

This is the row that matters for Google Images, and it has nothing to do with format choice.

The 116 are concentrated: 69 on slack.com, 25 on www.wired.com, 21 on www.nytimes.com, one on vercel.com. Google's page is direct about this shape — "We recommend that you always specify a fallback URL using the src attribute" — because some crawlers do not read srcset or <picture>. An <img> with no src is an image that only exists once something else runs.

The 113 extension-less URLs are a different story: they are image optimiser endpoints, 35 on linear.app, 31 on www.notion.com, 27 on nextjs.org, 17 on supabase.com. The format is negotiated at request time, so the URL cannot tell you what comes back. Google's same page adds a line worth reading next to that: "It's also a good idea to have the extension of your filename match with the file type."

Nobody declares a type on picture sources

Seven of the 27 sites use <picture> at all: stripe.com, substack.com, webflow.com, www.notion.com, www.nytimes.com, www.shopify.com and www.wired.com. Between them they ship 179 <source> elements, and 46 declare a type. Every one of those 46 says image/webp.

The other 133 sources declare no type, which means they are switching on media or resolution rather than on format support. Not one <source> in the panel declares image/avif. That is the mechanism the format upgrade is supposed to travel through, and on these 27 homepages it is carrying WebP or nothing.

What this means for you

Two moves, in this order.

1. Give every <img> a real src. It costs one attribute and it is the only one Google's page says it reads for Google Images. Do this before touching formats.
2. Add AVIF as a <source type="image/avif"> above your WebP source, keep the WebP, and leave a JPEG or PNG in the img src as the fallback. The panel says almost nobody has done this, which also means the pattern is not yet a crowded signal.

If your images sit behind an optimiser that returns a format based on Accept, you have already skipped both steps in a way this measurement cannot see — the URL keeps its extension-free shape whatever the server decides. Related on the same panel: srcset on 1,664 homepage images, and the method side in image seo best practices. The layer above all of it — whether the page gets fetched and quoted at all — is what QueryWin works on.

What this run cannot tell you

Which format actually arrived. We did not request a single image, so for the 113 extension-less URLs we do not know what bytes come back, and even for the 1,425 with an extension a server could be content-negotiating underneath. We also cannot see any image loaded by script after the page renders, and file size is entirely absent from this run — nothing here measures whether the WebP files are smaller than the PNGs sitting next to them.

Common questions

How did you measure this?

One fetch per homepage on 2026-08-28 with a desktop browser user agent, parsing the delivered HTML and reading the extension from each src after removing the search string and fragment. Buckets are mutually exclusive, so the four rows add to 1,675.

Is AVIF safe to use yet?

Google Search lists AVIF among the formats it supports for images in an img src. Browser support is what the <picture> fallback exists for, and this panel shows two sites relying on that pattern rather than none.

Does SVG count as an image for search?

It is on Google's supported list, and it is the most common extension here at 487 of 1,425. Most of those are icons and logos rather than content images, which is a distinction this measurement does not make.

Should I convert my PNGs to WebP?

Nothing in this run answers that. It counts what 27 homepages ship, with no page weight, no load timing and no ranking data attached to either column.