Convert PNG to AVIF
Re-encode a PNG as AVIF, which pays off heavily on photographs and transparency and costs bytes on small flat graphics.
How it works
PNG stores every pixel exactly, so a PNG holding a photograph is a lossless container carrying sensor noise at full price. Measured on 7 August 2026: a 512x512 photographic PNG of 473,831 bytes came back as 24,580 bytes of AVIF at quality 65, keeping 5.2 per cent of the original. An 800x600 photograph with a graduated alpha channel went from 224,566 bytes to 22,338. The transparency survives the conversion untouched, because AVIF stores alpha as a separate plane beside the colour planes and nothing has to be composited onto a background first.
That pairing is the strongest argument for the format. A photograph with soft transparent edges previously had two homes and neither was good. PNG holds the alpha and charges lossless rates for the photograph underneath it. JPEG has no alpha channel at all, so the edge must be flattened onto a colour picked in advance. AVIF holds both at lossy rates.
The size where PNG wins
An AVIF is a still frame of an AV1 video, so every file carries ISO base media container boxes and AV1 sequence headers before any picture data. Downscaling one flat two-colour logo and encoding each size at quality 65 puts the crossover near 30 pixels square. At 32x32 the AVIF was 462 bytes against 527 of PNG. At 27x27 it was 470 against 452, and PNG had taken the lead. At 8x8 the floor showed plainly: 334 bytes of AVIF against 162 of PNG, for a picture of 64 pixels.
Above that threshold the lossy comparison swings hard the other way, and a screenshot is the clearest case. A 1447x740 capture of a confirmation dialog, 60,573 bytes as a PNG, encoded to 9,479 bytes at quality 65. Anti-aliased text survives it. Decoding that result and comparing it with the source raster gave a mean absolute error of 0.28 out of 255, a worst case of 63, and 0.38 per cent of samples off by more than 8. The error concentrates on hard edges, where it reads as faint ringing. Judge it at the size the image will actually be viewed rather than zoomed in.
Lossless AVIF, and the narrow case for it
The lossless setting here is genuinely bit-exact. Six test images were encoded with it on, decoded again and compared sample by sample against the source raster: zero differing bytes on all six, maximum difference nought. What lossless does not do is win on size. On flat artwork it was consistently larger than the PNG it replaced, at 30,037 bytes against 10,268 for the logo, 35,220 against 11,913 for an illustration with alpha, and 62,343 against 60,573 for the dialog capture.
Photographs are where lossless AVIF earns anything, and it earns very little. The 512x512 photograph came back at 450,468 bytes against 473,831, a saving of 4.9 per cent for 782 milliseconds of work. So the setting is worth reaching for when exactness is a hard requirement and the picture is photographic. Everywhere else the PNG already holds the smaller answer, and the result panel reports the increase rather than hiding it.
The second cost is time
AV1 intra coding searches, and the search is charged per pixel with no previous frame to borrow from. On an Intel Core i7-12700KF the 1447x740 dialog took 3,849 milliseconds at the default effort, against 517 milliseconds to re-encode the same pixels as an optimised PNG. Dropping the encoder to Thorough took it to 11,364 milliseconds for a picture that is barely one megapixel.
On flat content the slow setting does buy something. The dialog capture measured 12,605 bytes at Fast, 9,479 at Balanced, then 9,236 at Thorough: a quarter smaller across the first step, and almost nothing after it for three times the wait. Balanced is the setting worth defaulting to, and Fast is the one to reach for on a batch.
Who can open the result
Browsers arrived at AVIF between 2020 and 2022. Chrome 85 shipped decoding on 25 August 2020, Firefox 93 followed on 5 October 2021, and Safari 16 completed the set on 12 September 2022. Any current browser will render one.
Away from the browser the picture is thinner and later. macOS gained system-wide AVIF in Ventura, released 24 October 2022, so a Mac on an earlier release shows nothing in Preview or Quick Look. Upload forms are the recurring trap, since a form that filters on file extension has no .avif entry to match against. Convert back before sending: AVIF to PNG returns a lossless raster and is offered as the next step.
Questions
Which requests does this page make while converting?
The code and wasm chunks for the PNG decoder and the AVIF encoder, all from this origin, and none of them carrying your image. Open the Network tab before dropping the file and watch it: once those chunks have loaded, no further request is made. The encode runs in a Web Worker on your own processor and the download comes from a blob URL created inside the tab.
Why did my converted icon come out bigger than the PNG?
AVIF has a floor and PNG does not. Container boxes and AV1 sequence headers are written before any picture data, which measured 334 bytes on an 8x8 image where PNG needed 162. PNG's row filters reduce a run of identical pixels to almost nothing and carry no comparable fixed cost. Below roughly 30 pixels square, keep the PNG.
How long will a large PNG take?
Between 0.4 and 3.8 seconds per megapixel at Balanced on an i7-12700KF, and the spread is content rather than size: a 1052x1052 flat logo took 401 milliseconds while a 1447x740 screenshot of almost the same pixel count took 3,849. The encoder is one wasm call that never yields, so the progress bar sits still while it runs and Cancel cannot interrupt it once started.
Should I keep the original PNG?
Yes, for anything that will be edited again. Quality 65 discards information the PNG held, and a later edit starts from the degraded copy rather than the original. Keep the PNG as the master and treat the AVIF as the delivery copy. For a small flat graphic the PNG is the better delivery copy as well, since lossless AVIF measured two to three times its size at every dimension tested.