PNG to AVIF Converter

Why PNGs are big — and where AVIF fits

PNG is lossless: every pixel you put in comes back exactly, and the format pays for that guarantee in file size, especially for photos and busy screenshots. AVIF makes the opposite trade — modern lossy compression from the AV1 video codec — while keeping the one thing that usually chains images to PNG: real alpha transparency. A logo with soft shadows, a cut-out product shot, a UI screenshot with rounded corners — all of them stay transparent in AVIF, with the size change measured and shown for each file rather than promised in advance. The conversion is worth it for delivery: web pages, chat, docs. It is not an archival move; keep the PNG master. AVIF and HEIC share a container family but live under opposite legal regimes, which is why this site reads HEIC and writes only AVIF — the guide HEIC and AVIF: decoding and licensing walks through both halves of that story.

The honest details

• Transparency preserved: AVIF carries a full alpha channel; nothing is flattened. (Tested — a transparent PNG round-trips with its alpha intact.)
• Measured, not promised: every row shows real input bytes, real output bytes, and the computed percent change — including "larger — keep your original" when a small, flat-color PNG beats the encoder.
• Lossy by design: the quality slider (default 50) trades fidelity for bytes. Pixel-exact work should stay in PNG.
• A few seconds per image, on your device: AV1 encoding is CPU-heavy; the fast preset is deliberate, the row reports the actual encode time, and no target-size mode is offered because eight search probes at seconds each would be dishonest UX.
• Encoded by libavif + aom locally: libavif with the aom AV1 encoder (BSD-2-Clause, under the AOM patent grant — royalty-free, unlike HEVC/HEIC), compiled from pinned upstream source to WebAssembly, self-hosted, and running in a bounded worker only in your browser. Details on the methodology page.
• Verified output: every AVIF is re-sniffed and re-decoded before its download button appears.

The sections below open each of those claims up: what the detector reads, what the planner decides, what the encoder is, what the re-encode strips, and how the result is checked — with every figure computed at build time by the engine that processes your files.

What the detector reads from a PNG

The first thing this lane does with a dropped file is read its leading bytes and run them through the same content detector every tool on the site uses. PNG's signature is the 8 bytes \x89PNG\r\n\x1a\n. The examples here are constructed, not taken from any real file: handed a byte array built at build time to hold exactly those 8 bytes and nothing more, the detector returns PNG. Nothing else is inspected at this stage — not the extension, not the chunk list, not the pixel data. Handed a second constructed array holding only the first 7 of those bytes, the same detector returns no recognized format: a file cut off inside its own signature is reported as unrecognized rather than guessed at.

The filename's extension is checked second and separately, so a wrong name cannot steer the conversion. An illustrative file called diagram.png, whose constructed leading bytes are FF D8 FF, comes back from the check as actual JPEG, claimed PNG, mismatch true. This lane accepts PNG sources only: the row for such a file says what the bytes actually are and points to the converter that takes that format to AVIF, instead of encoding a JPEG under a PNG label. Two caveats other lanes carry do not apply here. PNG is not among the containers the planner treats as animatable, so the plan's first-frame flag for this pair is false and no "first frame only" notice appears; and because the detector reads PNG's signature only, it makes no claim about what the chunks after it contain.

The plan for PNG to AVIF: no flattening, one quality

Before a pixel is touched, a pure planning function decides what the conversion will do, and the figures below are its actual return values for PNG to AVIF with this page's defaults. The output MIME type is image/avif. Flatten onto a background: false — the AVIF target's alpha capability in the engine's table is true, so transparent pixels are handed to the encoder as transparent pixels. The plan still carries a background field (#ffffff), but nothing on this lane reads it; compare the PNG to JPEG plan, where the flatten flag is true and the page must ask for a colour before converting. Quality is 0.5 on the engine's scale, which runs from zero to one; the quality mapper turns it into 50 on the whole-number scale from 0 to 100 that the encoder takes — the number the slider shows before you touch it, and libavif's own default as the engine records it.

Moving the slider changes one field of that plan and nothing else. At an illustrative slider position of 80, the plan's quality is 0.8 on the engine's scale and the encoder receives 80 back; at the planner's floor it is 0.05, encoder 5. The planner validates rather than clamps: asked for an illustrative 0.04, just under that floor, it refuses with "Quality must be between 0.05 and 1.", and asked to apply a quality to a lossless target — a PNG to PNG plan with a quality option — it refuses with "This output format is lossless and has no quality setting.". That second refusal is the engine's way of stating the difference between the two formats: PNG has no quality dial (its lossy flag is false); every AVIF this lane writes is lossy (flag true).

The output name swaps the extension for the target's canonical one, .avif, and leaves the stem alone. On illustrative names: logo.png becomes logo.avif; Screenshot 2026-10-02.PNG becomes Screenshot 2026-10-02.avif, because extension case is ignored; hero.v2.final.png becomes hero.v2.final.avif, because only the last dot counts; and a file named simply scan, with no extension, becomes scan.avif.

The encoder: libavif + aom, running in your tab

The browser's own canvas encoders produce PNG, JPEG, and WebP; AVIF output comes from one of the two self-hosted encoders on the site. This page encodes with libavif (© Joe Drago and contributors) driving the aom AV1 encoder (© Alliance for Open Media), both BSD-2-Clause under the Alliance for Open Media Patent License, with the license and patent-grant texts shipped beside the module at /vendor/avif/LICENSE.txt, /vendor/avif/LICENSE-libavif.txt, /vendor/avif/LICENSE-aom.txt, and /vendor/avif/PATENTS-aom.txt. The module is fetched from this site's own origin only when a file is actually dropped and runs in a bounded worker in your tab; how its files are pinned — immutable upstream commits, every vendored file's size and SHA-256 checked by tests — is set out once, on the methodology page and in the decoding and licensing guide, rather than restated on every lane.

One engine constant and one pipeline fact shape the encode. The constant is the lane's speed preset, 8, chosen on measured encode time in a single-threaded build; the engine records the choice beside the constant, and each row reports how long its own encode took. The pipeline fact is that the decoded pixels reach the encoder as a plain RGBA buffer: the PNG is decoded by the browser with createImageBitmap and imageOrientation: 'from-image', drawn to a canvas, read back, and handed to the worker — the PNG's own compressed data is never passed through, so the AVIF is a fresh encode of the pixels, not a re-wrapping of the file. Two things follow for this pair in particular. The PNG's transparency travels in that buffer's alpha channel, and because the AVIF target's alpha capability is true, the worker receives it as alpha rather than as pixels composited over a colour. And the PNG brings no quality of its own to inherit — the engine's table records PNG as not lossy (false) with no default quality — so the only quality in the encode is the slider's. The engine's source-only list — formats it decodes but never writes — is GIF, BMP, HEIC; AVIF is deliberately absent from it, and the reason, the opposite legal regimes of HEVC and AV1 as the methodology page states them, is the subject of HEIC and AVIF: decoding and licensing.

What a PNG loses in the re-encode

Because the output is a fresh encode of decoded pixels, everything that was stored beside the pixels in the PNG is gone: EXIF (including GPS location, camera model, and timestamps), colour-profile tags, and text chunks. The site presents this as both a feature and a caveat, because it is both — a converted image cannot leak where it was taken, and equally, copyright fields and ICC profiles are lost, so originals should be kept. Orientation is applied during decoding, before metadata is discarded, so uprightness survives even though the orientation tag does not. The pixel values themselves pass through the browser's canvas before encoding, the same path every converter on this site takes. For a PNG, the stores in question are its text chunks and colour-profile tags; the detector never reads them, because it stops at the signature, and the encoder never receives them, because it is handed pixels alone. The guide What re-encoding does to metadata covers the full list.

Why there is no "fit under N KB" control here

The JPEG lanes offer a target size, solved by measurement: encode at maximum quality, then binary-search the quality range, converging within eight encodes. That search is a pure planner the client drives one encode at a time, and whether a lane offers it is an engine flag. For the MozJPEG lane the flag is true; for this AVIF lane it is false. The reason is recorded beside the constant: a single AVIF encode of a large, detailed photo takes several seconds in the single-threaded build, so a search of up to eight probes would run tens of seconds per file. Rather than hide that behind a progress bar, the page offers the quality slider only, and each row reports the quality it used and how long the encode actually took on your device. There is a PNG-specific side to this as well. On the lanes that do search, a PNG input is never "PNG-compressed" — it is converted to a lossy format and labelled as such. This lane is that conversion by definition: the target's lossy flag is true at every position, the quality is chosen on the slider rather than found by probing, and the label is the page itself.

How the output is verified

A download button on this page means the AVIF has already been checked twice. First, the produced bytes are sniffed with the same magic-byte detector applied to inputs. AVIF is recognized by parsing the ISO-BMFF ftyp box — the major brand and every compatible brand read from the box structure, bounded by the declared box size, never by substring-searching the file — and looking for the avif or avis brand. An illustrative header built in this page's frontmatter, declaring the brands avif, mif1, miaf, is read back by that parser as AVIF; the same brand list reports false for the image-sequence check, since no avis brand is present. An encoder that produced anything else would be reported as an error, never offered as a mislabeled file. Second, the blob is re-decoded and its pixel dimensions compared with the plan; a mismatch is an error too. What the per-file check does not do is compare pixel values or alpha against the source PNG: the transparent round-trip is pinned by the site's tests, as the note above says, not re-measured on every file.

The sizes on a row are the two blobs' true byte counts, and the percent beside them is computed from those two numbers alone. The display rules are the engine's, and the invented byte counts below show them rather than state them — they are arithmetic, not figures to expect from any real image. 1,843,200 bytes becoming 460,800 reads "75% smaller". 1,000,000 becoming 905,000 reads "9.5% smaller", keeping a decimal place, while 1,000,000 becoming 900,000 reads "10% smaller" — from that row upward the figure is a whole number. 40,960 becoming 43,008 reads "5% larger — keep your original": an exact whole number drops its ".0", and growth is stated as plainly as shrinkage, with the advice attached. 2,048,000 becoming 2,048,100 reads "less than 0.1% larger — keep your original", a change too small to round to the smallest displayed step shown as less than it rather than as nothing; two identical counts read "same size". The site publishes no blanket compression percentages anywhere, because no percentage is true for every image.

What the tool cannot know

• Whether your AVIF will be smaller. Only encoding tells. A small, flat-colour PNG can beat the encoder, and when it does the row says so and the original is the file to keep.
• Whether the loss is acceptable for your purpose. The slider is a parameter the encoder takes, not a verdict this page delivers; it attaches no judgement to any value, and the only honest test is your own eyes on your own image.
• Where the file is going. This page cannot check whether the destination you have in mind reads AVIF. If it turns out not to, AVIF to PNG is the way back to a lossless file.
• What the PNG was before it was a PNG. The detector reads the signature; it has no view of how the pixels got there. A PNG saved from an already-lossy source is still a PNG to this lane and is encoded as one.

Common misreadings

• "The percent on my row is what AVIF saves." It is what this encode saved on this file, computed from two measured byte counts. The next file can land anywhere, including larger.
• "AVIF is HEIC under another name." They share a container family, which is why the same box parser detects both, but they are different codecs with different brands and different licensing — the reason this site decodes HEIC and encodes only AVIF.
• "Quality 50 means half the quality." It is a position on the whole-number scale from 0 to 100 that the encoder takes — the one libavif defaults to — and the engine's quality of 0.5, on a scale that runs from zero to one, mapped onto it. The page says nothing about what any position looks like.
• "Transparency gets flattened, like PNG to JPG." The flatten flag for this pair is false; no background colour is asked for or used.
• "The top of the slider is lossless." No position on this lane is. The target's lossy flag is true at every quality; pixel-exact work stays in PNG.
• "It takes seconds, so it must be uploading." The seconds are your own processor encoding AV1 in a worker inside the tab. The encoder is fetched from this site's origin, and the page's connect-src 'self' policy stops scripts here from sending data anywhere else — the methodology page shows how to watch the network tab and confirm it.
• "A .png is a PNG." The bytes decide. A misnamed file is reported as what it is, with a pointer to the lane that handles it.

Related tools

Photos living as JPGs go through JPG to AVIF. Need a different target? PNG to WebP also keeps transparency, encoded by the browser's own canvas encoder, and PNG to JPG is the flattened alternative — its plan asks for a background colour first. Coming back from AVIF, AVIF to PNG restores a lossless, editable file. The guides explain the engine behind every lane.

Frequently asked questions

Local processing: your images are converted and verified inside your browser and never transmitted. AVIF encoding by libavif and aom, BSD-2-Clause, self-hosted and used unmodified — see the methodology page for full attribution and how to verify the no-upload claim yourself.