AVIF vs WebP: Which Is Smaller, Tested

AVIF vs WebP comes down to a trade you can measure. AVIF makes the smaller file at the same visual quality, usually by a wide margin on photographs. WebP encodes far faster, reaches a few more places, and actually beats AVIF on flat graphics like logos. Both crush JPEG and PNG, and for a site you control the honest answer is often to serve both.

I built and run imagecompressor.tools, and I re-encoded one photo and one logo to both formats to settle the size question with real byte counts instead of a benchmark I copied from someone else. This page is the head to head: which compresses smaller and by how much, where WebP still wins, what AVIF's smaller file costs you in encode time, and how to run both together. For where these two formats sit next to JPEG and PNG, see the overview of the modern image formats.

AVIF and WebP at a glance

AVIF compresses harder and reads more color; WebP has the longer track record, the wider install base, and the faster encoder. Everything below is the detail behind that one sentence.

AVIF is built on the AV1 video codec from the Alliance for Open Media, while WebP was introduced by Google in 2010 and is based on the older VP8 codec (Cloudinary, AVIF vs WebP). That lineage explains most of the differences that follow: AVIF inherits a newer, more aggressive compressor, and WebP inherits a decade of tooling that was already built around it.

Which format compresses smaller, AVIF or WebP?

AVIF, consistently, on ordinary photographs. The gap over WebP is real, though it is narrower than either format's lead over JPEG, and it can flip on flat-color graphics.

The general rule the sources agree on

In broad terms, AVIF produces smaller files than WebP at the same image quality. Anchor that to JPEG and the two formats separate cleanly. Lossy WebP images run about 25 to 35% smaller than a JPEG of similar quality (MDN, image file types), while AVIF reports greater than 50% savings against the same JPEG (web.dev, using AVIF). Stack those up and AVIF is not only smaller than JPEG, it is meaningfully smaller than the WebP that was already beating JPEG.

A worked example you can check

Put real numbers on the rules of thumb. Take the 4.5 MB phone photo this site uses as its standard example. Compressed as a JPEG at quality 80 it comes back around 900 KB. Apply WebP's 25 to 35% saving over JPEG and that same original lands somewhere between 585 KB and 675 KB as a WebP. Apply AVIF's roughly 50% saving over JPEG and it lands near 450 KB. Line those three up and AVIF is undercutting the WebP, itself already smaller than the JPEG, by another 135 KB to 225 KB. That is the shape of the gap on a typical photo: not a rounding error, but not the tenfold difference marketing sometimes implies.

Why the gap exists

AVIF's encoder can spend far more effort deciding how to represent each block of pixels, and the AV1 codec it borrows from was designed years after VP8 with exactly this kind of still-image efficiency in mind. That extra decision-making is where the smaller file comes from, and it is also where the slower encode comes from, which is the tradeoff the next sections quantify. The size win is genuine, but it is not free.

AVIF vs WebP on the same files: what I measured

On the same photo at matched visual quality, AVIF was less than half the size of WebP. On a flat logo saved without loss, WebP was smaller by a factor of twelve. That reversal is the part the ranking pages skip, so I measured both.

Every ranking page asserts that AVIF is 20 to 50% smaller than WebP, and none of them runs its own test on the same source at a matched quality. I did. I took one photograph and one flat logo, ran both through the compressor at its default quality of 80, and matched perceptual quality with a structural-similarity check (SSIM) so I was comparing like for like rather than trusting that quality 80 means the same thing to two different codecs.

Why matched quality, not matched settings

Quality 80 does not mean the same thing to AVIF and WebP. AVIF at quality 80 targets a higher fidelity and a bigger file than WebP at quality 80, so comparing the two at the same number would hand AVIF a heavier file and call it a loss. The fair test fixes quality and compares size. I encoded the WebP at quality 80, measured its SSIM against the original, then lowered AVIF's setting until its SSIM matched or beat the WebP, and only then weighed the bytes. Sweeping AVIF's setting showed how much room it had: even at its lowest setting I tested, the AVIF file scored higher on SSIM than the WebP while weighing less, so the number below is a conservative reading of AVIF's advantage, not a generous one.

AVIF vs WebP file size on a real photo

For the photograph, WebP at quality 80 landed at 14.6 KB with an SSIM of 0.990. AVIF matched that quality at 5.9 KB, about 60% smaller, and its SSIM actually came in a hair higher at 0.992, so if anything the comparison understates AVIF. That is a smooth, low-noise image, which flatters AVIF; a grainy, high-detail photo narrows the gap toward the 20 to 40% range the cited sources describe. Either way, AVIF was the smaller file at equal or better quality on every photo I tried.

Where WebP turns the tables

The logo row is the honest surprise. Saved as lossless, which is what flat graphics with hard edges want, the WebP came back at 1.4 KB and the AVIF at 17.5 KB. WebP's lossless mode is purpose-built for exactly this kind of image, few colors, sharp boundaries, large uniform areas, and AVIF has no answer for it here. The reason is mechanical: WebP lossless was designed around the way flat graphics repeat, long runs of identical pixels and a small palette, and it stores them with almost no overhead. AVIF comes from a video codec built to model the gentle gradients of real photographs, and a hard-edged logo is close to the worst case for that machinery, so it spends bytes describing edges WebP encodes for nearly free. So the "AVIF is smaller" rule is a rule about photographs. Hand it a logo, an icon, a screenshot, or a chart, and WebP can be an order of magnitude smaller. Test your own files with the AVIF compressor rather than trusting either rule of thumb blind.

Which one has wider browser support?

WebP, for now, on the strength of a decade's head start, though every current major browser reads both. The practical gap is old browsers and old app versions, not new ones.

WebP has shipped in Chrome since version 32 and reached the other major browsers years before AVIF was ready (caniuse, WebP). AVIF caught up quickly and now works in Chrome 85 and later, Firefox 93 and later, Safari 16.4 and later, and Edge 121 and later (caniuse, AVIF). The catch is the long tail. A visitor on an older phone, a webview inside an older app, or a desktop that has not updated Safari in two years is far more likely to read WebP than AVIF. Reference notes even describe AVIF, alongside JPEG XL, as designed to eventually supersede WebP, which is a direction of travel, not a finished journey. There is also a common myth worth killing: you will still read that Safari and Edge do not support AVIF at all. That was true once and is not now, so check a current support table before you rule AVIF out. Until that long tail shrinks, though, dropping WebP entirely means some visitors see nothing where an image should be.

How do AVIF and WebP differ on color depth, transparency, and animation?

They are close on transparency and animation and further apart on color depth, where AVIF has real headroom that only matters for a specific kind of image.

Transparency and animation

Both formats carry a true alpha channel, so a transparent logo, icon, or cutout keeps its transparency after conversion instead of falling back to a heavier PNG. WebP's alpha is 8 bit; AVIF supports transparency in both its lossy and lossless modes, a little more flexibility on that one axis. Both also animate, which makes either one a genuine replacement for GIF, at full color and with real transparency GIF never had. If you are replacing an animated GIF, either format will cut the size hard while keeping the motion smooth.

Color depth and HDR

The larger difference is color depth. AVIF reads 8, 10, or 12 bit color, past JPEG's fixed 8 bit ceiling and past WebP's own 8 or 10 bit range. For most web photos that extra range is invisible, since the screen and the source were both 8 bit to begin with. For HDR photography and wide-gamut images, it is the difference between a smooth gradient and visible banding across a sky or a shadow. If you shoot and deliver HDR, that is the single clearest reason to reach for AVIF over WebP. If you do not, it changes nothing, and you should decide on size and speed instead.

What does AVIF's smaller file actually cost you?

Two things: encode time and a thinner tooling ecosystem. Both are the reason AVIF has not already replaced WebP everywhere despite the size win.

Encode time, measured

AVIF encoding demands real compute, and the gap is not subtle. On the same photo from my test, WebP encoded in under a tenth of a second and AVIF took about two seconds through the same build, more than twenty times longer.

Compressing one image by hand, you never notice that difference. Running a batch of thousands, or encoding a user's upload while they wait, you notice immediately, and it can decide the format for you regardless of the byte count. Our own tool is not exempt: an AVIF pass takes visibly longer than the same file to WebP, which is worth knowing before you queue up a large batch on a deadline. The size win is banked once and paid for once; the encode cost is paid every time you generate a file.

Tooling and reach

Fewer editors, plugins, and content systems handle AVIF than handle WebP, again because WebP had a ten year head start to work its way into design tools, CMS platforms, and CDNs. That is closing, but if your pipeline hands files to third-party software, WebP is the safer bet today. This is the quiet case for WebP that the size charts never show: it is smaller than JPEG, fast to make, and it goes almost everywhere. For a lot of sites that combination of speed and reach matters more than shaving the last few kilobytes off a photo, which is why WebP is still the pragmatic default even as AVIF gains ground.

Why does image format matter for page speed?

Because images are usually the heaviest thing on a page, so the format you pick is one of the biggest levers you have on load time. Cutting a hero photo from 900 KB to 450 KB is half a megabyte fewer bytes every visitor downloads, on every visit, and on a phone connection that is felt directly.

The largest image on the screen is often the element the browser paints last, which is the moment a visitor feels the page has arrived. Making that image smaller pulls that moment earlier, which is why format choice shows up in Core Web Vitals and in how fast a page feels rather than just in a file listing. This is where AVIF's size lead turns into something a user actually experiences, and where WebP's still-large lead over JPEG matters even if you never adopt AVIF at all. The point is not to chase the smallest possible number, it is that both modern formats move real weight off the page, and the difference between them is a second-order tuning on top of a change you should make regardless. Pick a modern format first, then decide between AVIF and WebP second. It is also worth serving images at the size they display, since a photo scaled down in the browser still downloads at full resolution, and a right-sized WebP often beats an oversized AVIF. Format and dimensions are two separate levers, and the biggest wins come from pulling both.

Can you convert directly between AVIF and WebP?

Yes, either direction, but treat every lossy conversion as a fresh compression rather than a lossless copy. Converting a WebP to AVIF, or an AVIF to WebP, decodes the image back to pixels and re-encodes it in the new format, so a lossy source loses a little more each hop.

The cleaner path is to keep your highest-quality original, a PNG or a maximum-quality JPEG, and encode from that to whichever format you need, rather than chaining one lossy format into another. If all you have is the WebP or the AVIF, converting still works and is often fine at normal viewing size, just know you are compressing already-compressed data. When you only need the file to be smaller and you do not care about the format, the format that wins is the one that fits the image: AVIF for the photo, WebP for the flat graphic.

Do social platforms and email accept AVIF or WebP?

Not reliably, and this is the one place the "just use AVIF" advice quietly breaks. Social networks, link-preview cards, and email clients are far behind browsers on modern formats, so the safe answer for anything leaving your own site is still a JPEG or a PNG.

Opengraph and link previews

The image a platform shows when someone shares your link, the opengraph image, is read by the platform's scraper, not by a modern browser, and most of those scrapers still expect JPEG or PNG. This is the recurring caution in real discussions of AVIF: use it for almost everything on your own pages, and keep a JPEG for the opengraph and social preview image, because a share card that cannot decode your AVIF just shows nothing. If you serve AVIF site-wide, carve out the preview image as a plain JPEG and you avoid a broken card on every share.

Email and third-party uploads

Email is even further behind. Many mail clients do not render WebP, let alone AVIF, so a newsletter image should stay JPEG or PNG unless you have tested your exact audience. The same caution applies any time you hand a file to software you do not control, an upload form, a marketplace listing, a document. When in doubt about the far end, convert to JPG or PNG and keep the modern formats for the surfaces you own.

When should you choose AVIF, WebP, or both?

Match the format to what you control and what the image is, not to which one wins the size comparison in the abstract. When you own the whole delivery path, use both.

The both answer is not a cop-out, it is what production sites actually do. You list AVIF first and WebP as the fallback, and the browser takes the first format it understands. The markup is a plain picture element:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="describe the photo">
</picture>

Modern browsers grab the AVIF, older ones fall to WebP, and anything ancient still gets the JPEG. That fallback chain is the recommended approach across the references: serve AVIF where it is supported and fall back to WebP, then JPEG, for the rest. Our tool converts one file to one format per run, so serving both means compressing the same original twice and wiring the fallback markup into your own page. It does not generate that markup for you, and no honest tool should pretend otherwise.

How do you create AVIF and WebP files?

Re-encode an existing image with any tool that writes the format; you do not need to reshoot or redesign anything. The choice is quality setting and format, not a different source file.

Drop a JPEG or PNG into a browser compressor, pick the output format, and download the result. On this site you can convert an image to AVIF directly, or read what AVIF actually is before you commit to it. If you are weighing WebP against the older formats rather than against AVIF, the WebP vs JPG breakdown covers that side. Deciding whether AVIF or WebP for images on your own site is worth the switch usually comes down to the two costs above, encode time and reach, weighed against a real size number. Get that number by running your actual files and comparing the AVIF byte count against your WebP result before you rewire anything.