Convert AVIF to PNG

How it works

A still AVIF is one intra-coded AV1 frame in an ISOBMFF container. The AVIF to JPG page covers what that buys in compression; the part that matters here is the rest of the inheritance, because a video codec brings habits that a still-image format never had, and three of them survive the trip into a PNG.

Chroma, and why the PNG grows

The first is chroma. libavif defaults to 4:2:0 for stills, halving colour resolution in each direction, and AV1 profile 1 exists to carry 4:4:4 for people who need it. The choice is recorded in the file's av1C configuration box and in the sequence header, and this tool reads it back, so the result line names the format the image was actually coded in.

PNG has no subsampled mode: every stored pixel carries its own colour sample, so a 4:2:0 source is upsampled during decode and the PNG holds the interpolated chroma at full rate. The colour detail subsampling discarded stays discarded, and is now stored expensively. That, plus entropy coding designed in 1996, is why the byte delta here is a large positive number and why the AVIF remains the file to serve over a network. One economy does apply: oxipng drops the alpha channel when every pixel is opaque, which is why the result line often reports RGB rather than RGBA.

Ten bits in, eight bits out

The second is sample depth. AVIF carries 8, 10 or 12 bits per channel, signalled by high_bitdepth and twelve_bit in the AV1 sequence header, and PNG holds 8 or 16, so a lossless path exists on paper. This is not the path taken here. The shared decoder in this suite asks libavif for 8-bit RGBA, and that is exactly what arrives: a 10-bit AVIF encoded during development came back as a Uint8ClampedArray of width × height × 4 bytes, one byte per channel, the same buffer an 8-bit source produces.

So the extra precision is quantised away before the PNG encoder is handed anything, and the result line names the source depth rather than implying it was preserved. On a 10-bit gradient the visible cost is banding. HDR is worse: a PQ or HLG transfer curve over BT.2020 primaries has no meaning to an 8-bit sRGB PNG. PNG's third edition, a W3C Recommendation of 24 June 2025, does add a four-byte cICP chunk that can label BT.2100 PQ and HLG, plus a 24-byte mDCV chunk for mastering display volume. This encoder writes neither. Keep the AVIF as the master when the grading matters.

Film grain is a coding tool, not an effect

The third is grain, and it is the surprising one. AV1 treats film grain as something to remove before encoding and redraw after decoding. The encoder denoises the picture, stores a parametric model of the noise it took out, and sets film_grain_params_present in the sequence header; the decoder synthesises grain from those parameters onto every frame it outputs. Honest grain costs a great many bits to code and almost none to describe, so the trade favours the encoder heavily.

The consequence for conversion is specific: a grain-synthesised AVIF holds no grain in its coded pixels, and the texture you see was drawn at display time. Decoding to RGBA runs that synthesis once, and the PNG stores the outcome as permanent pixel values that the next encoder in the chain will treat as detail.

Measured this session on a 512×512 test image encoded twice at the same quality, once with aom's grain modelling and once without, the AVIF fell from 51,747 bytes to 23,058 while the PNG converted out of it rose from 279,827 bytes to 355,718. Note the direction of that second number. The coded picture in the smaller file is the denoised one, so a PNG holding only what was coded would have been smaller as well; it grew by 27% instead, which is the synthesis arriving in the output.

This tool reads the sequence header flag and reports it, which is a statement about the stream rather than about one frame: the flag says grain parameters may be present, and the per-frame parameters that decide the strength and seed are not parsed here. Seeing it in the result line is the cue to keep the original if you ever intend to re-encode.

The applications that still refuse an AVIF

Browser support arrived years before application support, and applications are usually what sends someone looking for a converter. Android had no platform AVIF decoder until Android 12, released on 4 October 2021. WordPress rejected AVIF uploads until 6.5 on 26 March 2024. Pillow, the imaging library under a great deal of Python tooling, only shipped AVIF reading and writing in its own wheels at 11.3.0 on 1 July 2025; before that a separate pillow-avif-plugin build was needed. Java's ImageIO still has no AVIF reader in the standard library.

PNG went out as a W3C Recommendation in 1996 and as RFC 2083 in March 1997, and nothing in current use refuses one, which is the whole argument for converting. The decode and the encode both run in a Web Worker on your own machine, so the file never leaves the tab.