AVIF to PNG Converter

Nothing to download: your browser is the decoder

This page fetches no decoder. In the methodology page's words, current Chrome and Edge, Firefox 93+, and Safari 16.4+ decode AVIF natively, so AVIF to PNG uses the browser's own codec with a runtime feature probe and a plain-language notice when a browser cannot. The engine records that arrangement in its native-only decode list — AVIF — the formats it marks as decoded by the browser's own codec with no vendored fallback, on purpose; asked whether AVIF is on that list, the engine answers yes. The list is not a verdict on the other formats the engine decodes (PNG, JPEG, WebP, GIF, BMP, HEIC): in the methodology page's words, every other tool here decodes with the browser's own codecs, and HEIC is the exception that loads a decoder. The native-only entry marks where the site deliberately vendors nothing. The probe is a decode, not a version check: when the page loads it asks the browser to decode a tiny known-good AVIF, and only if that fails is the notice beneath the drop zone revealed. Nothing about your browser's name or version is consulted, which is why the notice can be trusted when it appears and trusted to stay hidden when it does not.

Decoding goes through createImageBitmap with imageOrientation: 'from-image', so any orientation the file declares is applied as the pixels are produced. From there the lane is short: the decoded bitmap is drawn to a canvas and written out by the browser's own PNG encoder. No vendored codec runs on this page in either direction. The self-hosted modules the site keeps under /vendor/ serve other lanes — libheif on the HEIC pages, libavif + aom on the pages that produce AVIF, MozJPEG on the Compress JPEG lane — and none of them is fetched here.

What the detector sees in an .avif file

The first thing the tool does with a file is read its leading bytes. PNG, JPEG, WebP, GIF and BMP announce themselves with fixed signatures; AVIF does not. It is an ISO-BMFF container, so the detector looks for an ftyp box at the front and walks it field by field: a big-endian size in the first four bytes, the ASCII tag ftyp, then the major brand, a minor-version field, and however many four-character compatible brands fit before the declared size runs out. Every brand is read from its fixed offset — the detector never substring-searches the file for the letters avif. The declared size is clamped to the bytes actually present; a box whose declared size cannot hold the size, type, major-brand and minor-version fields is rejected outright, so the same two-compatible box declaring 15 bytes is unrecognized while declaring 16 yields the brand list avif — the major brand alone, because the declared size ends before the first compatible — and is AVIF. A brand that is not printable ASCII ends the brand list, and an unreadable major brand rejects the box. A file is AVIF when the list carries avif or avis, unless an explicitly HEVC-coded brand (heic, heix, hevc, hevx) is also present, in which case HEIC wins. Every verdict in the table was produced at build time on a box constructed from the brand list shown.

Reading the rows: a major brand of mif1 — one of the structural HEIF brands the methodology page lists among the HEIC brands — still resolves to AVIF when avif sits among the compatibles, because an avif or avis brand anywhere in the list outranks the structural brands. On their own the structural brands resolve to HEIC: the box listing only mif1 and miaf is HEIC, and this page would refuse it. The mixed box that lists both heic and avif is HEIC, by precedence; drop such a file here and the row refuses it as HEIC rather than AVIF and points you to the HEIC converter instead, since a page built for one source format does not quietly accept another. The box declaring a size of 0 is unrecognized: the parser rejects it before reading a brand, so a hostile header cannot push the read past the buffer. The 11-byte slice is unrecognized for the same reason — too short to be a box at all. Only the avis brand sets the image-sequence column to yes, and that column is what drives the first-frame caveat below.

Names are compared, not trusted. After detection the filename's extension is checked against the verdict. An invented poster.avif wrapped around the still box reports a mismatch of no. The same bytes named poster.png are detected as AVIF while the name claims PNG, mismatch yes: the row says so, the conversion runs from the actual AVIF content, and the download is named poster-converted.png — a suffix, because poster.png would otherwise shadow the file you dropped. Named poster.heif, the extension claims HEIC and the mismatch is yes; the bytes are still AVIF, and that is what gets converted.

The plan for AVIF to PNG: three flags and no quality

Before any pixel moves, a pure planning module takes the detected source and the target and returns a plan. For this pair, computed at build time by the same function the tool calls on your file:

• Encoded as image/png, the MIME type handed to the browser's encoder; the download carries the .png extension.
• Flatten over a background: no. The capability table says PNG holds alpha, so the flag is off and no background colour is composited — the plan still records its default of #ffffff, and never uses it.
• Quality: none. PNG is lossless in the capability table, so the plan carries no quality and the page shows no slider.
• First frame only: yes. The planner sets this flag from the source format alone — AVIF can be an image sequence under the avis brand, so every AVIF plan carries it — while the row's "first frame only" note waits for the detector's sequence verdict on the actual file: yes for the sequence box in the table, no for the still box. A still AVIF therefore converts whole even though its plan carries the flag.

The planner refuses rather than guesses. Asked for this conversion with an illustrative quality of 0.8 on the engine's zero-to-one scale, it returns "This output format is lossless and has no quality setting." — the engine's own wording, and the reason no quality control exists on this page. The contrast with the JPEG lane is one flag: the same AVIF source planned to JPEG sets flatten to yes, because JPEG cannot hold alpha. That single difference is why this is the lane that keeps transparency, and why AVIF to JPG asks for a background colour and this page does not.

The encoder: the browser's own PNG writer

PNG output on this lane is written by the browser's PNG encoder through the canvas. The methodology page names the browser's PNG, JPEG and WebP encoders and, beside them, the two self-hosted ones; this lane uses the PNG encoder and neither self-hosted module. The plan passes image/png and no quality parameter; there is nothing to tune and nothing to vendor. That makes this page different from JPG to AVIF and PNG to AVIF, which load the self-hosted libavif + aom encoder, from Compress JPEG, which runs MozJPEG, and from the HEIC pages, which load libheif: the licence texts under /vendor/libheif/ and /vendor/mozjpeg/ and the licence and patent-grant texts under /vendor/avif/ describe modules this page never fetches. The guide restates those licensed facts in the methodology page's words; here, the only code that touches your pixels is the browser's and the site's own page logic.

What a lossless target means mechanically: the encoder stores the pixels exactly as the canvas holds them, alpha included, so re-saving the PNG later adds no further generation of loss. What it cannot do is reach behind the decode. The PNG is a faithful copy of the picture as your browser decoded it, not of the picture that was encoded into the AVIF: whatever the AVIF's own compression discarded, if it discarded anything, stays discarded. The conversion preserves; it does not restore.

How the download is named

The output name keeps your stem and swaps in the target's canonical extension, png. Computed at build time on invented names: photo.avif becomes photo.png; IMG_0427.AVIF becomes IMG_0427.png, the stem's case untouched; hero.v2.final.avif becomes hero.v2.final.png, because only the last dot marks the extension; a file with no extension at all, download, becomes download.png; and a path such as exports/2026/banner.avif is reduced to its final segment, banner.png. The only time a suffix appears is when the name would not change — the misnamed poster.png above, which becomes poster-converted.png.

What re-encoding strips

Canvas re-encoding strips all embedded metadata: EXIF (including GPS location, camera model and timestamps), colour-profile tags and text chunks. The methodology page presents this as both a feature and a caveat, because it is both — a converted picture cannot leak where it was taken, and equally, copyright fields and ICC profiles are gone, so originals should be kept. Orientation is applied during decoding, before metadata is discarded, so uprightness survives even though the orientation tag does not. On this lane the PNG the browser writes carries nothing from the AVIF but the pixels; there is no option to carry more, and the page does not pretend otherwise. The full account is in what re-encoding does to metadata.

How the output is verified

A download button on this page means the output has already been checked. The produced bytes are sniffed with the same detector applied to inputs — this lane must yield bytes the detector classifies as PNG, image/png behind a .png extension — so a browser silently substituting another format is reported as an error, never handed to you as a mislabelled file. The blob is then re-decoded and its pixel dimensions compared with the canvas that was drawn; a disagreement is an error, not a rounding note. Only then does the row show the verified format, the verified dimensions, and the output's true byte count beside the input's.

The percentage on a row is computed from those two measured byte counts for your file and nothing else. To show the wording without implying an expectation, here is the engine's arithmetic on invented counts: 240,000 bytes before and 3,120,000 after reads "1200% larger — keep your original"; 96,000 before and 88,000 after reads "8.3% smaller"; identical counts of 50,000 read "same size". None of these is a measurement of any real file. The site publishes no blanket compression percentages, because no percentage is true for every image — and a lossless landing can grow, in which case the row says "larger — keep your original" in the same breath as the number.

What the tool cannot know

• Whether the AV1 coding inside your AVIF discarded detail, or how much. The PNG preserves the image as it decodes; nothing on this page measures or judges picture quality.
• Whether the result is right for its destination. The row reports a verified format, verified dimensions and a measured byte count; whether a form, an editor or a workflow will accept the file is not something the detector can read.
• What the dropped frames of an image sequence contained. When the avis brand is present the first frame is converted and the row says so; the remaining frames are not inspected.
• Your intent for a file whose box says HEIC. The detector reports what the brands declare, and a file that is HEIC is sent to the HEIC lane rather than decoded here.

Common misreadings

• "Converting to PNG improves the picture." It preserves the picture as decoded. Lossless describes what the encoder adds — nothing — not what the source already lost.
• "The page downloads a decoder." The native-only list is AVIF; no module is fetched. The probe decodes a tiny known-good AVIF and reveals the notice only when that decode fails.
• "A file named .png is a PNG." The invented poster.png above is AVIF by its bytes, converted as AVIF, and delivered as poster-converted.png.
• "There is a quality setting I am missing." There is not. The planner's answer to a quality on this lane is "This output format is lossless and has no quality setting."
• "An animated AVIF converts whole." The first-frame flag is yes on this plan, and a file whose box declares avis keeps its first frame only; the row says so.
• "PNG output is always larger." The site states no percentage in advance. The row measures your file and uses the engine's wording — "1200% larger — keep your original" on one invented pair, "8.3% smaller" on another — whichever the bytes dictate.
• "The notice means the site is broken." The notice is the probe's result: this browser could not decode the test AVIF. The decoder is the browser's own; the notice names the browsers the methodology page lists.

Related tools

Need a target that cannot hold transparency instead? AVIF to JPG plans a flatten over a colour you choose. Going the other way, PNG to AVIF encodes with the self-hosted libavif + aom module while keeping alpha, and reports the measured change per file. For editing pipelines that continue elsewhere, the Image Resizer works on the PNG you just made. The container questions — brands, decoders, licences — are in HEIC and AVIF: decoding and licensing; the other guides cover detection, the pipeline, and what re-encoding strips.

Frequently asked questions

Local processing: your images are decoded, converted, and verified inside your browser and never transmitted — see the methodology page for how to verify the no-upload claim yourself.