Convert AVIF to PNG

This is not the conversion you do to send somebody a picture. It is the one you do when the image is going into an editor, a design file or a build step — Photoshop, GIMP, Paint.NET, a sprite sheet, an app’s asset folder, a tool whose importer lists PNG and JPEG and stops there. What those destinations have in common is that the image will be worked on again, which changes what the right target format is.

Anything about to be re-encoded, layered, masked or cropped should be lossless while it is being worked on. Every additional lossy pass is paid for permanently, and the whole point of moving to PNG is that this conversion is the last one that costs anything. A JPEG would start a chain; a PNG ends it. That is the split between this page and the JPG one: the same source format, the opposite advice, because there the file is being handed to somebody and here it is being worked on.

PNG has been lossless since 1996, standardised as ISO/IEC 15948, and it writes out exactly the pixels it is given. The conversion adds no compression artefacts of its own and no further softening: what the AVIF decoded to is what the PNG holds, byte for byte in the picture.

That is a narrower promise than it sounds and it is worth being precise about it. If the AVIF was compressed by a website — and almost every AVIF anyone holds was — then the smoothing, the lost fine texture and the flattened gradients are already part of the picture. A lossless container around a lossy image is still a lossy image. PNG stops the damage; it does not reverse it.

The size difference here is not a detail, it is the defining property of the pair. AVIF describes a picture as compactly as a modern video codec can manage; PNG stores every pixel and then compresses that losslessly. A few hundred kilobytes of AVIF routinely becomes several megabytes of PNG, and on a photograph the gap is at its widest, because photographs are exactly what AVIF is best at and what lossless compression is worst at.

Large files are the failure mode this registry lists against PNG, and this is where you meet it. Which makes the target worth checking: if the PNG is going back onto a web page, it is the wrong format and you have made the file five times bigger for nothing. If it is going into an editor, into a design tool or into a repository as a working asset, the size is what a lossless copy costs. It is also worth knowing before you start on a folder rather than a file, because a few hundred web images that fitted comfortably in a mail attachment will not fit in one as PNGs.

Both formats carry a real alpha channel, so this conversion moves transparency across with nothing lost. Soft edges, feathered shadows, antialiased type on nothing, semi-transparent overlays: all of it survives at the same precision it had in the AVIF, and no background colour has to be chosen because none has to be invented.

That is the one thing the JPEG route cannot offer at any quality setting, because JPEG has no alpha channel in its specification. If the picture you saved is a logo, an icon, a product cut-out or a UI element that has to sit on an unknown background, PNG is not a preference here, it is the only correct target among the widely accepted formats.

The tell that you needed this page rather than the JPG one is a white rectangle appearing behind something that was supposed to float. That is not a mistake in the conversion — it is JPEG doing the only thing it can with an alpha channel it has no way to store — and it cannot be undone afterwards, because by then the transparent pixels are white pixels like any other.

PNG supports up to sixteen bits per channel and AVIF supports up to twelve, so on paper a high-bit-depth AVIF could survive the trip. In this engine it does not: every image is decoded into an eight-bit RGBA buffer before anything else happens, so the PNG that comes out is an eight-bit PNG whatever the source held.

For images saved off web pages that is a difference on paper only — they were eight bits per channel when they were served. It matters if the AVIF came from a camera pipeline or an HDR export and you intended to grade it afterwards, because the headroom for that grading is gone at the decode step rather than at the encode step. If you have the original, keep working from the original.

You will notice the control missing and it is deliberate. A lossless encoder has nothing to trade: there is no dial between fidelity and size because the fidelity is fixed at exact. The only settings that apply here are the maximum width and whether metadata is dropped.

The maximum width control is the one that actually reduces the file, and it does it honestly — fewer pixels rather than a worse description of the same pixels. It sits at 0, which keeps the original size. If the PNG is enormous and you know it will only ever be displayed at 800 pixels wide, setting that here is far better than compressing a lossless format, which is a contradiction anyway.

After the PNG is written it goes through oxipng at optimisation level 2, which re-examines the filtering and compression choices and rewrites the file smaller. Nothing about the picture changes — the pixels that come out are the pixels that went in — so this is free size, not a quality setting in disguise.

It is the reason a PNG from this page is usually smaller than one saved out of a graphics program that did not bother. The saving is a percentage rather than a multiple, so it does not change the arithmetic against the AVIF: a small optimised PNG is still a large file next to the AVIF it came from. Level 2 is chosen because the levels above it spend a great deal more time for a very small further gain, and this runs in a browser tab while somebody waits.

PNG’s natural material is screenshots, diagrams, charts and flat artwork, and that is precisely the content AVIF handles least well. On flat colour with hard edges AVIF’s advantage narrows and it can produce a file larger than a well-made PNG of the same image, which is measured on this site’s own WebP and AVIF comparison.

So for that kind of image the conversion is often not a compromise at all. A screenshot of an interface, a bar chart, a logo, a scan of a line drawing: converting one of those from AVIF to PNG can cost far less than the general rule suggests, and the result is both lossless and universally readable. Photographs are where you pay.

AVIF is a delivery format. It exists to make a page load quickly and it is regenerated whenever the page is rebuilt, which is why the formats it competes with are all delivery formats too. Nobody archives in it and no editor treats it as a project file.

PNG is on the other side of that line. It is lossless, every chunk in the file carries a CRC so corruption is detected rather than silently displayed, and it is read by everything back to the mid-nineties. If the AVIF is the only copy of an image you care about, converting it to PNG and keeping that is a defensible way to stop the copy degrading — though it is second best to finding whatever produced the AVIF in the first place.

The decoding and the encoding both happen in the browser tab, on your processor, so nothing is sent anywhere and there is no account, no queue and no daily allowance. The free ceiling is 100 MB per input file, which no web-delivered AVIF will approach. Drop a folder in and the results come back as a single ZIP with per-file progress.

The practical benefit is that it works on a machine that cannot open the format at all. If double-clicking the AVIF does nothing and the editor you need it in refuses to import it, the browser is the one piece of software on the machine that definitely reads it, and this runs inside the browser.