AVIF to PNG Converter — Lossless & Transparent

PNG and JPG solve different problems, and picking the right target format saves you from doing the conversion twice. PNG is lossless: every pixel of the decoded AVIF image is preserved exactly, with no recompression artifacts at any step. It also supports a full alpha channel, so logos, icons, illustrations, screenshots with rounded corners, and any other graphics with transparent areas survive the conversion intact — no white box around your artwork.

JPG, by contrast, is lossy and drops transparency. For photographs destined for the web, that is usually fine (and our AVIF to JPG converter handles that case). For anything with sharp edges, text, flat colors, or transparency, PNG is the safer target: edges stay crisp, text stays readable, and transparent backgrounds stay transparent.

Because PNG is supported everywhere — every browser, every operating system, every image editor, every office suite — converting AVIF to PNG is the most reliable way to make a modern image editable and shareable in older toolchains without losing a single pixel of detail. The format dates back to 1996, and nearly three decades of universal support means nobody on the receiving end will ever reply with "I can't open this."

AVIF is a brilliant delivery format and a frustrating working format. It was designed to ship finished images to browsers at tiny file sizes, not to move work between designers, editors, and print vendors. These are the situations we see over and over — if any of them sound familiar, you are in the right place.

A designer gets a client logo as an AVIF file and needs it in Figma. The client exported their new logo from a modern web pipeline, so it arrives as a 2400×800 AVIF weighing 96 KB. Figma's AVIF support is inconsistent depending on platform and version, and even when it imports, you want a canonical asset that behaves predictably in every plugin and export preset. Convert it to PNG and you get a lossless file — in this case about 1.4 MB — with the alpha channel fully intact, so the logo drops onto any artboard, over any background color, with no white rectangle glued to it. That PNG becomes the source of truth you archive next to the project.

Your copy of Photoshop 2019 refuses to open the file. AVIF did not become a native Photoshop format until the 26.8 release in June 2025, which added open, edit and save support. Anything older — including the 2019 build that plenty of studios still run on locked-down machines — either shows an error or does not list the file at all. Some versions in between could pull an AVIF in through the Camera Raw plug-in, but that was never a path worth planning a workflow around. Instead of upgrading a working setup mid-project, convert the AVIF to PNG and keep going. The PNG opens in every Photoshop version back to the 1990s, and because PNG is lossless, you can edit, re-save, and export again without the generation-loss spiral you'd get re-saving a JPG over and over.

A print shop receives AVIF layout assets from a client. The brand team sends over images pulled from the company website — all AVIF, because that's what the site serves now. The prepress workflow expects PNG or TIFF at 300 DPI, and the RIP software has never heard of AVIF. Converting to PNG keeps every pixel exact, which matters enormously for print: flat brand colors stay flat, no compression ringing around typography, no banding in gradients. A 4500×3000 poster asset might go from a 1.1 MB AVIF to a 14 MB PNG — a meaningless trade when the alternative is a blurry or artifacted print run of 5,000 copies. The same logic applies to roll-up banners, business cards, and packaging dielines — anywhere a RIP will rasterize your file, lossless input means the only quality decisions happen in your design tool, not in a converter's compression settings.

A developer is wiring up the favicon pipeline. AVIF is not a safe favicon format in 2025 — support in browser tab rendering, RSS readers, social crawlers, and older Safari versions is still patchy. The boring, correct choice remains PNG: a 32×32 favicon and a 180×180 apple-touch-icon, both PNG, both expected by conventions that have held for a decade. When the design team hands you the mark as an AVIF, one conversion gives you the PNG master you can resize down to every required size without touching quality settings.

You already tried a converter and it destroyed the transparency. This is the most common complaint in this whole category: a tool decodes the AVIF, composites it against a white background, and hands you a flattened image. Now your icon has a ghost halo you can't remove without manual masking. The alpha channel problem is real and we cover exactly how it's handled below — the short version is that semi-transparent edge pixels and gradient fades carry over untouched here, which is the entire reason PNG is worth choosing for graphics in the first place.

AVIF stands for AV1 Image File Format, and the name is the whole story: it is a still image wrapped in the AV1 codec. AV1 is the royalty-free video format built by the Alliance for Open Media — Google, Netflix, Amazon, Apple, Microsoft, Mozilla, Intel and Cisco among the founding members — with the specification finalized in 2018. The AVIF container spec followed in 2019, and it borrows the same ISO base media file structure that HEIC uses, which is why an .avif and an .heic file can look structurally similar even though the codecs inside have nothing in common.

The still-image profile uses only intra-frame coding: every frame is compressed on its own, with no reference to frames before or after it. That is exactly what a still image needs, and it is also why AVIF gets away with a fraction of what video codecs normally spend on motion compensation. On top of the compression, the format carries real capability: 8, 10 and 12-bit color, HDR transfer curves (PQ and HLG), wide-gamut primaries such as Display P3 and BT.2020, a full alpha channel, and film grain synthesis that re-generates noise at decode time instead of storing it.

The size numbers are the reason the format spread so fast. Against JPEG at matched visual quality, an AVIF typically lands 30–50% smaller. Against PNG the gap looks even more dramatic — usually 60–80% — but that comparison flatters AVIF, because PNG is lossless and has no quality dial to turn down. A lossless format will always lose a size contest against a lossy one, and pretending otherwise is how people end up disappointed by the PNG they get back.

One detail worth filing away: AVIF does have a lossless mode, inherited from AV1's lossless intra coding. It is almost never used in practice, because on most content the resulting file is larger than an equivalent PNG while being far slower to decode. If you see a lossless AVIF in the wild, it came from a deliberately configured pipeline rather than from a normal export.

These two formats were built thirty years apart for different jobs, and the gap shows in every spec sheet line. Understanding the trade-offs tells you when PNG is the right target and when you should reach for JPG instead.

• Compression approach. AVIF is built on the AV1 video codec and is lossy by default — a photographic image that takes 5 MB as a PNG might compress to 400 KB as an AVIF at visually identical quality. PNG uses DEFLATE, a lossless algorithm from the 1990s, and simply cannot compete on size. Expect converted PNGs to run 5–15× larger than the AVIF source.
• Transparency. Both formats support a full alpha channel, including semi-transparency — this is one of the few areas where they tie. JPG supports no transparency at all, which is why this comparison keeps coming back to PNG for graphics work.
• Color depth. AVIF supports 10-bit and 12-bit color, which is why it handles HDR photography so well. PNG is most commonly written at 8 bits per channel (the spec allows 16-bit, but tooling support is patchy). Converting a 10-bit AVIF to a standard 8-bit PNG involves a tonal step-down — invisible for most web imagery, but worth knowing if you work with HDR sources.
• Browser support timeline. PNG has worked everywhere since the late 1990s. AVIF landed in Chrome 85 in August 2020, Firefox 93 in October 2021, and Safari 16.1 in late 2022 — meaning any device, browser build, or embedded webview older than that cannot display it. That support gap is the whole reason conversion pages like this one exist.
• Editing and software support. Every image editor, office suite, email client, CMS, and print pipeline on Earth reads PNG. AVIF support in creative software is still rolling out — Photoshop added it in 2021, and plenty of tools (older GIMP builds, many DAM systems, most print RIPs) still don't read it at all.

The conversion is a decode followed by a re-encode, with no shared DNA between the two halves. Your browser hands the file to its native AV1 decoder, which produces a full RGBA raster in memory — four bytes for every pixel, alpha included. That raster is drawn onto a canvas, and the canvas encoder writes it out as PNG. The PNG side of the trip is where the work happens: each scanline gets a filter (None, Sub, Up, Average or Paeth) chosen per row to make the numbers more compressible, the filtered stream goes through DEFLATE, and the result is wrapped in chunks with CRC checksums so a truncated file fails loudly instead of decoding to garbage. Not one step in that chain is allowed to change a pixel value.

Which brings us to the misunderstanding this page exists to clear up. Converting a lossy AVIF to PNG does not make the image sharper. The decoder returns exactly what the AV1 encoder chose to keep, and the PNG then preserves that result perfectly — every soft edge, every blocky artifact, every smeared gradient, reproduced with absolute fidelity at several times the file size. "Lossless" describes the PNG step only. The container changed; the picture did not improve. If the AVIF was written at a low quality setting, no downstream format can put the detail back, because the detail is gone before the converter ever sees it.

Where lossless genuinely applies is narrower than most people assume. If the source AVIF was encoded in lossless mode, the PNG you get is bit-identical to the original image. But if that AVIF was itself produced from a PNG, the PNG you get back is not the file that went in — it is that file after AV1's lossy pass, with the damage now locked in permanently. Each AVIF round trip compounds the loss; PNG-to-PNG never loses anything. The practical rule: convert to PNG to change what the file can be opened by, never to change how it looks.

AVIF signals color through CICP fields — primaries, transfer function and matrix coefficients — stored in the container's nclx box, rather than always shipping an embedded ICC profile. Most AVIF files on the web are sRGB and convert without drama. The exception worth knowing about is Display P3, the wider gamut Apple's devices export by default. Its reds and greens reach meaningfully further out than sRGB can express, and those are precisely the colors that fall off the edge of a standard browser canvas.

A canvas works in sRGB unless you explicitly ask for something else, so a Display P3 AVIF pushed through the ordinary path gets squeezed into the sRGB gamut, and any color outside it is clipped or compressed. On a photograph this is almost always invisible. On a brand color that was deliberately specified outside sRGB, it can be measurable, and the shift happens silently — nothing in the output file tells you it occurred. If exact wide-gamut color is the entire point of the asset, convert in a color-managed desktop tool rather than a browser.

Bit depth is the second quiet change. AVIF handles 10-bit and 12-bit color; a canvas PNG is 8 bits per channel. Ten bits give you 1,024 steps per channel, eight bits give you 256, so the conversion is a four-fold reduction in tonal resolution. Most images never come close to using the full range and come through untouched. Smooth gradients and clear skies are where you would notice, and only if banding was already close to visible in the source. HDR files lose something more: the PQ or HLG transfer curve has to be tone-mapped into the SDR range a canvas works in, and that mapping cannot be undone from the PNG. For serious HDR grading, the right target is a 16-bit TIFF pipeline, not a browser.

Almost every "free online converter" works the same way: your file goes up to someone's server, a worker process converts it, and the result comes back down. That model exists because it used to be the only option. It no longer is. Browsers have shipped a native AVIF decoder for years, so the machine you are reading this on already has everything required to read the format — the server was never doing anything your own CPU could not.

This tool decodes your AVIF files with your browser's native decoder and re-encodes them as PNG locally, in memory. No upload happens at any point — which matters especially for design assets, unreleased product shots, or anything covered by an NDA. You can convert with your network disconnected once the page has loaded. A 20-file batch of typical web-sized images usually finishes in a few seconds on a laptop from the last five years; the bottleneck is decoding, not downloading.

The honest trade-off is memory. A 20-megapixel image decoded to RGBA occupies roughly 80 MB before the encoder has allocated anything, and a canvas copy plus PNG compression buffers push peak usage well past that. On a desktop this is unremarkable. On a phone it is the real ceiling: mobile Safari has historically capped canvas area at around 16.7 megapixels, so a 48-megapixel photo straight off a recent handset can fail on iOS while the identical file converts instantly on a laptop. The workaround is unglamorous and effective — convert large batches in chunks of a few dozen, close other tabs, and give the browser a moment between passes.

• No quality slider needed — PNG encoding is lossless by definition, so there is nothing to tune. Every output is pixel-identical to the decoded source.
• Transparency preserved — the alpha channel of the source AVIF is carried over to the PNG, including semi-transparent gradients.
• Batch queue with per-file status — drop dozens of files, watch each one convert, then download them individually or as one ZIP archive.
• Failed files never block the queue — a corrupted or non-AVIF file is flagged with a reason while the rest continue converting.

The privacy model is worth spelling out because it's unusual for converter sites: your files are never transmitted anywhere. There is no server-side processing queue, no temporary storage bucket, no retention policy to read. The conversion math happens in the same browser sandbox that rendered this page, and closing the tab wipes everything.

Transparency is where AVIF-to-PNG conversions go wrong most often, so let's be precise about what's happening. An AVIF image with transparency stores an alpha plane alongside the color planes — every pixel carries both its color and its opacity, from 0 (fully invisible) to fully opaque. When a lazy converter decodes that image, it sometimes composites the pixels against white (or worse, black) and throws the alpha plane away. The result looks fine on a white page and disastrous anywhere else: a pale halo around every edge, hard white fringes on anti-aliased curves.

This tool keeps the alpha plane end to end. A logo at 40% opacity around its soft edges comes out of the PNG at exactly 40% opacity around its soft edges. Semi-transparent gradient fades — the kind used in modern UI artwork and product shots with soft shadows — survive untouched because PNG has native per-pixel alpha, not the 1-bit on-or-off transparency of older formats like GIF.

There's an easy way to verify any conversion yourself: drop the resulting PNG into Figma or onto a dark desktop background, or open it in any editor and look at the checkerboard pattern behind the artwork. If the soft edges blend into whatever is behind them, the alpha channel made it through. If you see a white box, the converter flattened it — come back and run it through this page instead.

The whole workflow is three gestures, and nothing here sends data anywhere. Drop your AVIF files onto the tool area at the top of this page — or click it to browse — and each file enters the queue with its own status line. Conversion starts immediately, one file at a time, using your browser's built-in decoder. When a file finishes, you can download that PNG on its own, or wait for the batch and grab everything as a single ZIP. A typical logo converts in well under a second; a 24-megapixel photo from a modern phone camera takes a couple of seconds because PNG encoding of that many pixels is real work, even done locally.

A couple of habits worth building into the workflow. Rename the outputs to match the convention the receiving tool expects — print vendors usually want descriptive names with dimensions, and favicon pipelines expect exact filenames like apple-touch-icon.png. And if the destination is a layout that specifies 300 DPI, set that DPI value in your design tool when you place the PNG: the pixels are already lossless and print-ready, the DPI tag is just metadata about how large those pixels print on paper.

PNG files are larger than the AVIF source, and that is the price of lossless output rather than a flaw in the converter. A photographic AVIF in the 200–500 KB range commonly becomes a PNG of 2–8 MB depending on dimensions and detail — a factor of three on a clean studio shot, closer to ten on a dense landscape with fine texture. Graphics with large flat areas grow least, because PNG's DEFLATE compression handles repeated identical bytes extremely well; photographic detail grows most, because every pixel is different and DEFLATE has nothing to latch onto.

Whether that growth is a fair trade depends entirely on what happens to the file next, and the answer splits cleanly in two.

• Worth it — you need to edit the image without stacking another generation of compression loss on top; you are feeding a print RIP that only accepts PNG or TIFF; you are handing the file to software that predates AVIF; you are building favicons or app icons that convention expects as PNG; or you are archiving a master next to the project so the asset survives whatever format the web moves to next.
• Not worth it — the image is destined for a web page. A 6 MB PNG on a product listing is slower to load than the 400 KB AVIF you started with, and it buys nothing: the browser could read the AVIF all along. Serve the AVIF, or convert to JPG or WebP if you need broader reach. The same applies to email attachments and anything a customer will open over mobile data.

If size matters more than pixel-perfect fidelity or transparency, converting to JPG with a quality of 80–90% produces far smaller files — our online AVIF to JPG tool is built for exactly that trade. The decision rule is simple: if you need exact pixels or transparency, PNG is the correct choice; if you need the smallest possible universal format and can accept a quality trade-off, JPG is the pragmatic one.

One more practical note: if you're not sure what's inside an AVIF file you were sent — dimensions, whether it even has transparency, whether it's a photo or a graphic — our AVIF viewer opens it right in the browser so you can inspect it before deciding which format to convert to.

If the conversion has to happen inside a build pipeline, or you simply want the same result twice from the same input, three command-line tools cover the job. They all do the same thing this page does — decode AV1, re-encode PNG — and they all share the same limitation, which is that none of them can recover detail the AVIF encoder already threw away.

FFmpeg handles AVIF through its libdav1d decoder, which is present in standard builds from version 5.0 onward. The explicit pixel format keeps the alpha channel rather than dropping it:

ffmpeg -i input.avif -pix_fmt rgba output.png

ImageMagick 7 reads AVIF when it has been built against a libheif with AV1 support compiled in, which is true of most distribution packages but not all. The command is the same shape as any other format conversion:

magick input.avif output.png

avifdec is the reference decoder shipped with libavif, the library the format is specified against. It is the most literal implementation available and the least likely to surprise you on an unusual file:

avifdec input.avif output.png

Two more commands earn their place. To inspect a file before converting it — dimensions, bit depth, whether an alpha plane exists at all — avifdec --info input.avif prints the container header without writing anything to disk. And to convert an entire folder, a shell loop is enough:

for f in *.avif; do ffmpeg -i "$f" -pix_fmt rgba "${f%.avif}.png"; done

If ImageMagick reports that AVIF is not a recognised format, magick -list format | grep -i avif tells you whether the delegate is missing; installing a build with libheif and libaom support fixes it. Everything above runs offline and never sends your files anywhere, which is the same privacy property this page offers, just with a terminal instead of a drop zone.

Abstract ratios like "5–15× larger" are hard to act on until you see them grounded in real assets. The three scenarios below cover the range of files that arrive here most often. Each one uses measured values rather than estimates.

Example 1 — a brand logo with transparency (2400 × 800 px). A company exports its updated logo from a modern web pipeline. The AVIF weighs 96 KB at the default quality setting, and the alpha channel carries a soft drop shadow around the wordmark. Decoded, that image occupies 2400 × 800 × 4 bytes = 7.68 MB of raw RGBA in memory. The PNG encoder applies Paeth filters across the large flat-color regions, bringing the final file down to roughly 1.4 MB — about 14.6× the AVIF. The alpha channel survives intact, and every edge of the shadow gradient matches the original pixel for pixel. The trade is obvious: 1.3 MB more on disk in exchange for a file that opens reliably in Figma, Illustrator 2018, a 2019-era Photoshop, and the print shop's PDF compositor — all at once, with no re-export needed.

Example 2 — a 20-megapixel landscape photo (5184 × 3888 px). Shot on a recent mirrorless camera, processed in Lightroom, exported as a high-quality AVIF for the company website at 1.2 MB. Raw RGBA footprint: 5184 × 3888 × 4 bytes = 80.6 MB. This is the image that saturates mobile browser memory limits. The resulting PNG lands at 11.8 MB, roughly a 10× increase, because fine landscape detail — individual leaves, textured rock, water ripples — provides almost nothing for DEFLATE to compress. At this size, PNG is the right choice only if the image is going into print prepress or being archived as a working master. For web delivery, keep the AVIF; for a 300 DPI magazine spread, the PNG is the correct format and the size is expected.

Example 3 — a 180 × 180 app icon (apple-touch-icon). The design team produced the icon as a 12 KB AVIF from a vector source. Raw RGBA: 180 × 180 × 4 bytes = 129.6 KB. PNG output: 34 KB — a 2.8× increase, unremarkable for a file this small. Flat brand colors and large uniform regions compress aggressively under DEFLATE, so icon-scale images land closer to the low end of the size-multiplier range. On a CDN that already serves hundreds of kilobytes of JavaScript, a 22 KB difference on the apple-touch-icon request is not measurable in page weight. The PNG is worth it simply because the HTML spec expects it and no browser has ever refused one.

PNG is often described as "just lossless," as if the compression is a single step. The format actually applies two stages in sequence, and understanding them explains why a flat logo compresses to a fraction of a photographic PNG of the same pixel count.

The first stage is the filter step. Before each row of pixels is handed to the compressor, an encoder picks one of five prediction schemes and subtracts the prediction from each pixel value. The five modes are None (raw bytes), Sub (difference from the pixel to the left), Up (difference from the pixel directly above), Average (average of the left and upper neighbors), and Paeth (the Paeth predictor, which picks whichever neighbor — left, above, or upper-left — is closest to the weighted average). The point of all this arithmetic is to make the byte stream as uniform and repetitive as possible before compression begins. A row of pixels where each value changes by only one or two units from its neighbor compresses to almost nothing. A row of random-looking photographic luminance values compresses poorly regardless of which filter is applied.

The second stage is DEFLATE, the same algorithm used in ZIP and gzip files. It combines LZ77 sliding-window matching — which finds repeated byte sequences and replaces them with references to earlier occurrences — with Huffman coding, which assigns shorter bit sequences to more common symbols. Together they are extremely good at uniform or slowly-varying byte streams and largely helpless against high-entropy data like fine photo texture. That is the mechanical reason a 400 × 400 product icon with a white background might come out at 12 KB as a PNG while a 400 × 400 crop of a gravel path comes out at 180 KB at the same dimensions: the icon has thousands of identical white pixels, and the gravel has no two adjacent pixels with the same value.

From a practical standpoint this means you can predict PNG size from visual content before converting. Logos, screenshots, UI mockups, diagrams, and flat illustrations will land on the low end of the size multiplier — often 3–6× the AVIF. Photographic content, especially landscapes, fur, fabric, and bokeh, will land at the high end — often 8–15×. When a converted PNG is unexpectedly large, the image itself is why, not the converter.

Most conversion mistakes trace back to a handful of wrong mental models. Clearing them up takes less time than debugging a bad result later.

Misconception 1: "Converting to PNG sharpens the image." PNG is lossless in the sense that no additional damage occurs after the decode step. It does not reverse damage that already happened. If the AVIF encoder ran at quality 60 and left visible block artifacts around sharp edges, every one of those artifacts is encoded faithfully into the PNG at several times the file size. The PNG is a perfect preservation of the decoded output, which is not the same as the original source.

Misconception 2: "A PNG can be converted back to the original AVIF."Once lossy AVIF compression has run, the discarded detail is gone permanently — no downstream format stores it, and no round-trip can recover it. Re-encoding a PNG back to AVIF applies a second generation of lossy compression to a file that was already degraded. Each generation multiplies the artifacts. Keep the original AVIF if you might need to re-export later.

Misconception 3: "PNG is better for web delivery than AVIF."For finished images on a web page, AVIF is almost always the better delivery choice. PNG exists for editing, compatibility, transparency in environments that do not support CSS compositing, print, and archival — not for serving content to browsers that already understand AVIF. A 6 MB PNG on a product page is a performance regression, not a quality improvement.

Misconception 4: "A browser converter is less accurate than a desktop tool."The browser's AVIF decoder is the same AV1 implementation used in Chrome, Firefox, or Safari for rendering images on every page you visit. It is not a simplified version. The decode output is the reference output. Desktop tools like FFmpeg or ImageMagick use different AV1 decoders — usually libdav1d or libaom — and may produce fractionally different results on edge-case files, but for ordinary AVIF images the outputs are indistinguishable.

Misconception 5: "All converters handle transparency the same way."They do not. The alpha channel in an AVIF is a separate plane decoded alongside the color planes, and a converter that composites the image onto a white canvas before encoding the PNG discards it silently. The resulting file looks correct on a white background and wrong everywhere else. The only way to verify alpha survived is to drop the PNG onto a dark or patterned background and check that soft edges blend naturally. White halos mean the alpha was flattened; smooth blending means it survived.

Switching a file from AVIF to PNG changes the container and codec but does not change anything about how assistive technology reads the image in a web page. Alt text, aria-label values, and figure captions are HTML attributes on the element that references the file — they travel with the markup, not the image. When you replace an AVIF source with a PNG in an img tag, update the src attribute and leave everything else unchanged. A missing or lazy alt attribute on an AVIF is still missing on the PNG; a well-written description survives the swap without editing.

Metadata inside the file is a different story. AVIF can carry Exif, XMP, and IPTC blocks in the container. When the decoder hands the raster to a canvas and the canvas writes PNG, those metadata blocks are not automatically transferred — they go through a separate path that most browser-based converters do not implement. If copyright, caption, or GPS data embedded in the AVIF matters to your workflow, inspect the original file with a tool like ExifTool before and after conversion and confirm which fields survived. A PNG written by a canvas encoder will at minimum carry the basic tEXt chunks for software and creation time; it will not carry Exif GPS coordinates unless the conversion path explicitly copies them.

DPI metadata is the most practically relevant field for print work. A canvas PNG sets no pHYs chunk by default, which means the file lands at 96 DPI in most applications — technically meaningless for a screen image, but visible as a wrong-size placement in InDesign or Word. Setting the correct DPI — 300 for offset print, 150 for wide-format, 72 for screen — is done in the receiving application when you place or import the file, not in the converter. The pixel dimensions are already there; you are adding metadata about intended print size, and that step belongs in the design tool that knows the intended output medium.

Support for AVIF is not a yes-or-no question — it arrived at a different time in every application, and plenty of software in daily professional use has not arrived at all. This is the practical map, with what to do about each row.

Read that table once and the argument for PNG over JPG in compatibility cases becomes obvious: every row that cannot open an AVIF can open a PNG, including the ones written in the 1990s. If you would rather have the smaller file and transparency is not a consideration, the AVIF to JPG converter trades the alpha channel for roughly a fifth of the weight. And if you are not sure which row your file belongs in, open it with the AVIF viewer first and see what you are actually working with.

Four formats compete for the same jobs, and the right one depends on three axes: does the image need to be lossless, does it carry transparency, and what software will open it? The table below pins each format to a real number so you can make the call without running test conversions.

The size multipliers above apply to a photographic AVIF at typical quality settings. Flat graphics compress far better under DEFLATE, so a logo PNG might land at 3× rather than 12×. The key take from the table: if you need both transparency and a smaller file than PNG, lossless WebP is worth a look — it beats PNG on graphics by 20–40% in most cases, supports full alpha, and works in every browser released since 2014.

PNG is not the only lossless target for an AVIF with transparency. WebP lossless (VP8L) achieves the same guarantee — no pixel changes from decode to output — at 20–40% smaller file sizes than PNG on most graphics. For an icon suite or a set of UI assets that will be served to modern browsers, that saving adds up fast. A 180 × 180 app icon that lands at 34 KB as a PNG typically comes in at 22–26 KB as a lossless WebP, with the alpha channel intact and the edge pixels identical.

The case for PNG over WebP is compatibility. WebP appeared in Chrome 23 (2012) and Firefox 65 (2019), and Safari only added support in version 14 (2020). Every piece of software older than those vintages — Photoshop before 22.4, InDesign before 2021, most print RIPs, older DAM platforms, and Windows 10 before a 2019 system update — will refuse to open a WebP file. PNG is readable on hardware from twenty years ago. If the file is destined for a web front-end built after 2020 and will never be opened in a design tool or sent to a printer, WebP lossless is the sharper choice. If the destination is anything else, PNG is safer.

There is no WebP lossless option in this tool — it outputs PNG. For lossless WebP from an AVIF, cwebp (the reference WebP encoder from Google) accepts PNG as input: encode to PNG first, then run cwebp -lossless input.png -o output.webp. The two-step process takes seconds and produces a file that is bit-for-bit identical in decoded pixel values.

Understanding the pixel path matters when a conversion produces unexpected output — wrong colors, missing transparency, or a file size that looks impossible. The steps below track a single RGBA pixel from the AVIF bitstream to the PNG chunk, with the places things can go wrong called out explicitly.

Step 1 — Container parse. The browser reads the ISOBMFF structure of the .avif file: the ftyp box identifies the file type, the mdat box holds the compressed bitstream, and the meta box carries color space signaling (nclx or icc), alpha plane references, and any Exif/XMP metadata blocks. A malformed container that fails here typically produces a decode error rather than a wrong image.

Step 2 — AV1 intra decode. The decoder reads the AV1 bitstream as an intra-only sequence: superblocks, transform units, quantization tables, and entropy coding are resolved into YUV (or RGB in rare cases) values. For a lossy AVIF, the quantization step is where detail was discarded during encoding — no downstream step can put it back. The decoder outputs a full-resolution YUV raster plus, if present, a separate alpha (AUX) plane decoded the same way.

Step 3 — YUV to RGB conversion. The color planes are converted from YCbCr to RGB using the matrix coefficients from the nclx box (typically BT.601 for sRGB web content). This is where a color-managed tool and a canvas differ: the canvas applies the matrix and clips to the sRGB gamut. A wide-gamut P3 AVIF gets silently gamut-mapped here; the output pixels are in sRGB, and no flag in the PNG tells the viewer that a gamut reduction occurred.

Step 4 — Canvas compositing (the alpha danger point). The RGB raster and the alpha plane are combined onto a canvas. A correct path draws the RGBA data onto a transparent (zero-alpha) canvas, preserving every alpha value. An incorrect path composites onto an opaque white canvas — then the canvas encoder sees fully-opaque pixels everywhere and writes a PNG with no alpha channel. The result looks fine on white pages and wrong everywhere else.

Step 5 — PNG encode. The canvas calls toBlob('image/png'). Each scanline gets a filter mode chosen to minimize entropy (Paeth for most photographic content, Sub for horizontal gradients, None for already-uniform rows). DEFLATE compresses the filtered stream. Chunks — IHDR, IDAT, IEND — are assembled with CRC checksums. The metadata blocks from Step 1 are not included unless the encode path explicitly copies them into tEXt or iTXt chunks.

The phrase "quality settings" means different things depending on which side of the conversion you are looking at. On the AVIF input side, quality was a dial the original encoder turned — typically a CRF (constant rate factor) value between 0 and 63, where lower numbers produce larger, higher-fidelity files. A CRF of 20–30 is typical for photographic web content; CRF 45–55 is the range where visible artifacts begin on most images. Once that encoding ran, the decisions are locked. The PNG step has no quality setting because it is lossless — the only output variable is compression level, which affects encode speed and file size but not pixel values. Level 6 (the browser default) balances speed and size well for most assets.

File size after conversion follows a predictable pattern based on image content. Flat graphics — logos, icons, UI screenshots, diagrams — compress aggressively under DEFLATE because large runs of identical or slowly-varying pixels give the LZ77 stage enormous repeated-match windows to exploit. A 1920 × 1080 screenshot might produce a PNG of 400 KB from an AVIF source of 150 KB: a 2.7× ratio, not the 10× you would see for photographic content at the same dimensions.

When file size matters and lossless output is still the requirement, three levers exist beyond format choice. First, resize before converting: a 2× linear scale-down reduces pixel count by 4×, which typically halves the PNG. Second, strip unused color channels — a grayscale PNG (PNG color type 0) occupies a third of the bytes of an RGBA PNG at the same dimensions. Third, post-process with a PNG optimizer like oxipng orpngcrush: these apply more exhaustive filter selection and DEFLATE parameter searches than a browser encoder uses, and commonly shave 15–25% off the output without touching a single pixel.

AVIF support arrived on a staggered schedule across every platform, and the gaps still matter anywhere legacy devices or embedded webviews are in the picture. The table below lists the first version with working decode support — not the version where the format was experimental or flag-gated, but the version a normal user would have received automatically through an update.

Any device that falls before these version cutoffs will display a broken image icon or skip the file entirely — they are not reading a degraded version, they are seeing nothing. PNG has no such table: there is no browser, OS, or piece of software released in the last twenty-five years that cannot open one. That single fact is what justifies the conversion in every compatibility scenario, regardless of file size.

For your own site, the safe pattern is to serve AVIF with a PNG (or WebP) fallback in a <picture> element: browsers that understand AVIF take the first source, everything else falls back to the PNG. When an external tool or partner workflow is the destination rather than your own front-end, skip the fallback complexity and send the PNG directly — it is universally readable and the size difference is irrelevant once the file lands in a design tool, a print queue, or an archive folder.