Convert PNG to AVIF

PNG is exact and expensive. It never discards a pixel, which is why it is the right format for a logo or a screenshot, and it is why a page carrying twenty of them is heavy enough for a performance report to complain about.

AVIF attacks that from the other direction. It descends from a modern video codec, and it applies that machinery to a single frame — which is why it commonly lands at half the size of the PNG or better for a photograph, keeps a real alpha channel, and still looks the same at normal viewing size. On a page of product images, that is the difference between a slow first impression and a fast one.

Most people arriving here already moved to WebP and are wondering whether the next step is worth it. On photographs it usually is: at comparable quality AVIF tends to come in another twenty to thirty per cent below WebP, and it handles gradients and smooth skies with noticeably less banding.

On the other half of the web the answer flips. Flat interface graphics, icons, charts and screenshots — the things PNG was actually designed for — compress so well already that AVIF sometimes produces a larger file than WebP. Convert five representative images of your own and compare the byte counts. It takes ten minutes and it beats any general rule, including this one.

AVIF encoding does far more work than PNG or WebP encoding. It searches much harder for structure it can describe compactly, and that search takes time — expect a noticeable pause per file, and several seconds for a large photograph, even on a fast machine.

The cost is paid once, on your computer, at the moment of conversion. Every visitor afterwards downloads a smaller file. That is a good bargain for site assets and a poor one for something you need converted right now, which is worth remembering when you drop two hundred files and go to make coffee.

AVIF carries a proper alpha channel, so the transparency that forced the image to be a PNG in the first place is not a reason to stay. A cut-out product shot, an icon with rounded corners, a logo that has to sit on any background colour — all convert with no fill colour to pick and no halo around the edges.

This is the main practical difference from converting to JPG, where transparency has to be thrown away and replaced with something, and it is why AVIF can replace PNG across a whole asset folder rather than only in the photographic parts of it.

The default sits at a level where the difference from the PNG is invisible at normal viewing size while the file is a fraction of the size. For photographs, screenshots and general site imagery, leave it there.

Raise it towards the top for images that will be zoomed into, or that carry fine text or thin one-pixel lines, where aggressive compression is easiest to spot. Lower it for large decorative backgrounds nobody inspects closely. The one thing to avoid is treating the converted file as the master — keep the PNG, because quality that has been given up cannot be recovered by converting back.

Browser support has not been the problem for years: Chrome, Edge, Firefox, Safari and the mobile browsers all display AVIF. If the image is going onto a web page, it will be seen.

The failures are elsewhere. Desktop image viewers, older phone galleries, chat applications, email clients and plenty of content-management upload forms still do not recognise the format. Do not email someone an AVIF and do not use it as the file a customer downloads — for that, send the JPG or the PNG. AVIF is a delivery format for web pages, not a general-purpose one.

The standard pattern is a picture element with several sources: AVIF first, WebP second, and the original PNG or JPG as the img fallback. Each browser takes the first format it understands and everyone gets a working image, so nothing has to be decided on the visitor’s behalf.

This only works if you keep the originals. Convert a copy of your asset folder rather than converting it in place, and keep the PNGs in version control — they are the source the next format will be generated from too, whenever it arrives.

Drop the whole directory. Each file converts in turn on your own machine with its own progress, keeps its filename with the extension swapped, and everything comes back as a single ZIP ready to drop into the build.

Because nothing is uploaded there is no queue, no per-file wait and no daily allowance — which matters more here than on most conversions, since AVIF encoding is the slow part and a hosted service would be charging you for that time on someone else’s processor.