Say your export menu has WebP and you add AVIF under it. Click WebP and the file is saved before you have moved the mouse. Click AVIF and there is a pause you can feel. The AVIF is supposed to be smaller, but by how much, and is that the same for every image? I build small internal tools for a content team and wanted numbers for that trade, so I put together a test page.

Some plain words first. AVIF and WebP are both image formats built to come out smaller than JPEG, AVIF being the newer one. An encoder is the code that turns raw pixels into one of those files. I ran both encoders as WASM, which means a C library compiled so it can run inside a web page: @jsquash/avif 2.1.1 (libavif v1.0.1 underneath) and @jsquash/webp 1.5.0. Everything here is Chromium 149 on one Apple M4 Mac, with each image scaled down to about 2 megapixels. AVIF was set to quality 50 and speed 6, using the multi-threaded build. Speed is the encoder's effort dial: a bigger number means less effort and a faster result, and 6 is the library default.

The awkward part is "same quality". I had no reason to think quality 50 in AVIF and some quality number in WebP mean the same thing, so I matched on SSIM instead. It is a score you get by decoding the output and comparing it with the pixels you started from, where 1 means identical. I computed it on luma only, the brightness part of the picture. Then I encoded each image as WebP at ten quality settings and worked out, by interpolating between them, how big a WebP would be at the exact SSIM the AVIF reached. Hence the ≈ on the WebP figures. Think of it as a kitchen scale: it can tell you two bags weigh the same, and it has no opinion on how they taste. Your eyes may still prefer one of two files with equal SSIM.

Table of AVIF and WebP sizes at matched luma SSIM and their encode times for four images

Read the coloured column first, then the last one. The two photos are from Wikimedia Commons, a lake by Jakub Fryš and a fruit stall by Josep M. Gracia, both CC BY-SA 4.0. The two screenshots are mock pages I rendered myself, a docs page and an admin table, so no real product is shown.

On the photos AVIF came out at 69% and 68% of the WebP size. The lake was 43,764 bytes against roughly 63,610, in 324 ms where WebP took about 113. On these two, three to four times the wait bought a file about 30% smaller. The text screenshot barely shrank: 172,174 bytes against roughly 180,295, which is 95%, for about three times the encode time. I had assumed screenshots would behave as one group, and the fourth row broke that. The table UI, big flat areas with thin lines, came out at 46% of the WebP size, and it took 1,513 ms where WebP needed about 85, around 17 times as long. I have not looked into why that one is so slow. At AVIF quality 60, 70 and 80 the ratios stayed close: 73%, 73%, 71% for the lake and 96%, 98%, 97% for the text screenshot.

To see how a finished tool handles this, I used ImgIng (https://imging.ai/), an online image tool with AVIF in its converter, and gave it the lake photo as a PNG. What follows is what I saw on its Chinese-language site. With AVIF selected its quality slider settles on 52, next to four content presets: photo 52, smooth 48, texture 56, graphics and text 60. It tagged the lake as a photo. The 2 MP lake took 1,678 ms from click to "done" on the first run, which included a one-off start-up step, and the 12 MP version took 1,579 ms. That was Chromium 149 only, one run per size, and I did not look at how it works inside. Those are whole waits measured from outside the page, a different kind of number from the encode times in my table, so I am not setting them side by side.

The converter panel after converting the 2 MP lake PNG to AVIF, showing 2.65 MB to 58.9 KB

This is its English interface after the same 2 MP conversion. The badge says Saved 98%. That compares the AVIF with the PNG I gave it, which says nothing about AVIF against WebP.

Four images at one size on one machine is a small sample, and I would not stretch "30% smaller" to photos in general. There is also a hole in my measuring. The AVIF files here are 4:2:0, meaning colour is stored at half the resolution of brightness in each direction, and a luma-only SSIM cannot see anything that happens to colour. Whether thin coloured lines or small coloured text go soft is something I did not test. What I do now, before adding AVIF to any export, is take one image typical of what that tool handles, encode it both ways, match the SSIM, and write down two numbers: the percentage and the milliseconds. Then I open both files and look.