PNG to AVIF: Measured Sizes, and When AVIF Loses

Converting PNG to AVIF in a browser is not something Chrome can do on its own. Chrome decodes AVIF natively but it has no AVIF encoder — the canvas API writes PNG, JPEG and WebP and stops there — so a converter that genuinely works inside the page is running a WebAssembly build of libavif, the reference encoder, in your own tab. That is what this one does, and it is the reason the numbers below are measurements rather than promises.

AVIF is worth the trouble on the right file and a waste of time on the wrong one. Nothing about the file name tells you which you have, so the only useful answer is a number. This post is that number, for four real files, read back out of the browser and then checked with a second, independent decoder.

What AVIF actually produced

Each of these came from running the tool on the live page and then reading the bytes Chrome wrote to disk. ImageMagick re-opened every output to confirm the format, the pixel dimensions and the alpha channel, so none of it is copied from the page's own result line.

• A 1600×1200 photograph, saved as a 24-bit PNG of 4,272,717 bytes, became 493,318 bytes of AVIF at quality 50. That is 88.5% smaller, and the row read 4.07 MB → 482 KB · 1600×1200 · q50.
• The same photograph at quality 35 became 248,365 bytes (94.2% smaller). At quality 80 it became 1,027,722 bytes (75.9% smaller).
• A 700×500 RGBA PNG of 2,394,992 bytes became 191,979 bytes — 92.0% smaller — with the transparency intact. Mean alpha was 0.5500 in and 0.5490 out.
• A 16×16 flat-colour PNG of 313 bytes encoded to 314 bytes of AVIF. The tool handed the PNG back and said so.

The last line is the one most converter pages leave out. On a small flat graphic AVIF is not merely unimpressive, it is larger — 313 bytes in, 314 bytes out — and a tool that hands you that file while badging it a success has made your page slower and told you it helped.

Why the win is so large on a photograph

A PNG is a lossless container. It has no concept of "close enough", so every pixel is stored exactly, and a photograph is mostly noise and gradients that compress badly under a lossless scheme. The same 1600×1200 image costs 4.07 MB as PNG and 482 KB as AVIF, and the difference is not one clever trick — it is that AVIF is allowed to throw away detail you cannot see, and then does it in a way that is far better at it than JPEG.

Three things do most of the work. AVIF stores colour at lower resolution than brightness, because human vision is much more sensitive to the latter. It codes the difference between neighbouring blocks rather than each block independently, so a smooth sky costs almost nothing. And it keeps more of the precision at low bitrates, which is exactly where a photo-sized file lives.

The practical consequence: the noisier and more photographic the image, the bigger the win. Smooth gradients, skin, foliage and skies are where AVIF earns its place.

Where AVIF loses, and why

AVIF is not free. It is a container, and a container has overhead — a file header, a colour profile, the box structure that tells a decoder what it is looking at. That overhead is trivial on a 4 MB photo and decisive on a 313-byte icon.

PNG, meanwhile, is genuinely excellent at flat colour. A 16×16 solid square compresses to almost nothing under PNG's own deflate filter, and there is no detail left for AVIF's better modelling to remove. So AVIF pays its overhead and gains nothing:

313 B · AVIF came out at 314 B — kept your PNG

That is a real result line from the tool. The default is to compare the two files and hand you whichever is smaller, because the alternative is a converter that reliably makes small images bigger. If you specifically need AVIF — a CMS that demands the format, a Lighthouse score to satisfy, a build pipeline that expects it — the fallback setting overrides the comparison, produces the AVIF anyway, and labels the row AVIF is larger with a +0%-style badge instead of a saving. You get what you asked for, and you are told what it cost.

The boundary sits somewhere between the two. A 900×600 flat-colour graphic of 5,004 bytes came down to 634 bytes — an 87% win — while the 16×16 icon lost. It is not about the format of the artwork, it is about how many bytes PNG had already squeezed out before AVIF was invited to try.

AVIF against WebP, on the identical file

WebP is the comparison most people actually care about, because it is the format they are probably using now. The site has a separate PNG → WebP tool, so the same 1600×1200 photograph went through both, in the same browser session, and both outputs were measured:

• Source PNG — 4,272,717 bytes
• AVIF at quality 50 — 493,318 bytes (88.5% smaller)
• WebP at quality 90 — 1,173,862 bytes (72.5% smaller)

AVIF came out 58% smaller than the WebP — not 58% of the original, 58% smaller than the other file. WebP already cuts the PNG by nearly three quarters, so the honest framing is that AVIF takes a good result and improves on it substantially, rather than rescuing a bad one.

One caveat on that comparison, because it is the kind of thing that is easy to overstate. Those are the two tools' defaults, and the defaults are not equivalent settings — AVIF quality 50 and WebP quality 90 happen to land at a similar visual standard, which is why they are paired here, but they are not the same number and no single pair of settings is a law. If you want to know which is smaller for your image at your setting, run both.

What quality does, in numbers

The quality slider is where people guess, so here is the same file at each of the tool's four presets:

• 35 — 248,365 bytes (94.2% smaller)
• 50 — 493,318 bytes (88.5% smaller)
• 80 — 1,027,722 bytes (75.9% smaller)

Notice that going from 35 to 50 doubles the file to buy a modest amount of detail, and going from 50 to 80 doubles it again to buy much less. Past roughly 65 the extra bytes are mostly noise the encoder is faithfully preserving. That is why 50 is the default: it is the point where the curve has already flattened and you are paying for the last thing you can see.

Quality 35 is a sensible choice when the image is decoration — a thumbnail, a card in a long article — and 65 or 80 when the image is the product. A photograph of a document is the awkward case: text is the one kind of content where AVIF's low bitrate advantage is weakest, so if legibility matters, convert a sample and look at it before converting the batch.

What is preserved, and what is not

Transparency is preserved. AVIF carries a full alpha channel, so unlike a JPEG conversion there is no white background and nothing to disclose. That was checked rather than assumed: a 700×500 RGBA PNG went in with a mean alpha of 0.5500 and came out with 0.5490, and the decoder read an alpha channel out of the result. The small difference is the alpha channel being lossily compressed too, at a setting high enough that it does not show.

Dimensions are untouched. A format conversion and a resize are different jobs, and this tool only does the first. 1600×1200 in, 1600×1200 out. If you also want fewer pixels, resize first and convert second.

Nothing else is touched. The file is not uploaded, not re-encoded when it does not need to be, and not renamed beyond its extension.

A failure worth knowing about, because we only found it by using the tool

There is a class of broken PNG that a browser will happily lie to you about. Chrome's PNG decoder is lenient: give it a file that was cut off mid-download and it parses the scanlines it managed to read, renders a partial image, and reports success. The API a converter calls returns normally.

That means a truncated PNG does not fail — it converts. On a large file the result is a mostly-blank AVIF a fraction of the size of the original, which arrives with a confident -99% badge on it. The badge is accurate about the bytes and completely wrong about the outcome: you would ship a blank image to production believing you had optimised it.

It was caught by driving the real page with a 220-byte fragment of a 4 MB PNG. The tool now checks that a PNG ends with its end-of-file marker before converting it, and says so instead:

This PNG is incomplete — its end-of-file marker is missing, so the file was probably cut short while downloading. The browser can still show the part it has, but converting it would produce a blank image. Download it again and retry.

An engine-level test could not have found this. The unit suite feeds the conversion function a file and checks the output; it has no way to know that the browser had already decided the broken input was fine. It took a real file, a real page and a real download to see it.

When you should not use AVIF at all

Three cases, and they are worth taking seriously rather than converting anyway.

Outside a browser. AVIF is supported by every current browser — Chrome 85, Firefox 93, Safari 16 — but support outside one is patchier. Some desktop editors, print workflows and older CMS uploaders still will not read it. If a file has to survive being emailed to someone who will open it in an old copy of an office suite, keep the PNG.

Small flat graphics. Measured above: it can come out larger. An icon, a logo, a simple diagram or a screenshot of a UI is often better served by PNG, or by WebP, or by nothing at all.

When the image is already small enough. If a PNG is 40 KB and looks fine, converting it is an afternoon of broken build scripts in exchange for a rounding error.

In every other case — photographs, hero images, anything with gradients or texture, anything large — AVIF is the best answer the web currently has, and the numbers above are what it does.

How to use it

1. Open the PNG to AVIF converter.
2. Drop in one PNG or a whole batch.
3. Leave quality at 50 unless you have a reason to move it. Choose 35 for thumbnails and decoration, 65 or 80 when the image is the point.
4. Leave the fallback on Give me the smaller file. That is what stops a small flat image being made bigger. Switch it to Give me AVIF anyway only when something downstream requires the format.
5. Read the before-and-after on each row before downloading. It states both sizes and the quality actually used, so you can see what happened instead of trusting a percentage.

Changing either setting re-runs the whole batch, so you can try quality 35, look at the result, and change your mind without starting over.

Nothing is uploaded

The decoding, the encoding and the size comparison all happen in your browser. Your images never leave your device — which matters more here than it sounds, because the files people convert are client logos, unpublished designs, product photography and internal screenshots.

You do not have to take that on trust. Load the page, disconnect from the internet, and convert an image. It still works, because nothing was ever being sent anywhere.

The short version

AVIF is dramatically smaller on photographs — 4.07 MB of PNG became 482 KB in the measurement above, and it beat WebP by 58% on the same file. It is larger than your original on small flat graphics, where PNG has already done the work. Quality 50 is the right default, transparency and dimensions are preserved, and nothing is uploaded.

And if the AVIF loses, you should get your own file back rather than a bigger one with a badge on it.