AVIF vs PNG: Lossy Delivery vs Lossless Editing

AVIF (AV1 Image File Format) is a still-image format derived from the AV1 video codec, standardized by the Alliance for Open Media. It was designed from the ground up for web delivery: aggressive lossy compression, wide color gamut, HDR support, and an alpha channel. The container is ISOBMFF — the same box structure used by MP4 files — which means software that cannot read ISOBMFF simply cannot open AVIF. That detail explains much of AVIF's compatibility story.

PNG (Portable Network Graphics) was published as a standard in 1996 as a patent-free replacement for GIF. Its design goal was lossless, portable storage of raster graphics. It has no concept of lossy quality levels. Every PNG decode produces bit-for-bit identical pixel data to the original. This predictability made PNG the default format for screenshots, icons, logos, design exports, and any image where exact pixel values matter more than file size.

The practical difference follows from these origins. AVIF trades some pixel accuracy for dramatically smaller files — it is a delivery format. PNG trades file size for perfect fidelity — it is an editing and archival format. Choosing between them is not a quality competition; it is a question of which property your workflow actually needs. Most of the confusion around "AVIF vs PNG" comes from applying a delivery format where an editing format is required, or vice versa.

For a direct comparison with the other major lossy format, see the AVIF vs JPG guide. If you need to convert files right now, the AVIF to JPG converter on the home page processes everything locally in your browser.

PNG compression is a two-stage process and neither stage is lossy. In the first stage, each row of pixels is passed through a prediction filter. The encoder chooses one of five filter types per row: None (raw values), Sub (difference from the left pixel), Up (difference from the pixel above), Average (average of left and above), or Paeth (a predictor that picks whichever of left, above, or upper-left is closest to a linear combination). The goal is to turn raw pixel values into small, predictable deltas — the output of a good prediction filter looks like mostly-zero differences with occasional spikes, which is far more compressible than raw RGB data.

The filtered data is then compressed with DEFLATE, the same algorithm used in ZIP files, which combines LZ77 back-references with Huffman coding. DEFLATE finds repeated byte sequences and replaces them with pointers, then encodes the remaining symbols with variable-length codes weighted toward frequent values. The result is lossless: the decompressor reverses the Huffman coding, reverses the LZ77 back-references, and inverts the prediction filters row by row, recovering every original byte.

This works well for images with large flat areas, sharp edges, and limited color variation — logos, diagrams, interface screenshots. It works poorly for photographic content with complex texture and subtle color gradients, because random-looking pixel differences compress inefficiently with DEFLATE. A photograph saved as PNG will often be several megabytes larger than the same image saved as a high-quality JPG, and many times larger than an AVIF at equivalent perceived quality. PNG has no mechanism to decide "this detail is imperceptible, discard it" — it must preserve everything.

AVIF uses the intra-frame coding mode of the AV1 video codec. Rather than predicting pixels from adjacent rows like PNG does, AV1 divides the image into superblocks (up to 128×128 pixels), predicts each block using directional intra-prediction modes derived from neighboring reconstructed blocks, computes the residual (the difference between the prediction and the actual block), applies a Discrete Cosine Transform or Asymmetric Discrete Sine Transform to that residual, quantizes the transform coefficients (this is where lossy information is discarded), and then entropy-codes the quantized coefficients with CABAC or ANS.

The quantization step is the fundamental difference from PNG. By setting a quantization parameter (called CQ or QP), the encoder decides how aggressively to round small transform coefficients to zero. A coefficient of 3 rounded to 0 is a small, mostly imperceptible error in one block. Summed across thousands of blocks, these small errors produce files that are far smaller than any lossless representation — but the original pixel values are gone permanently. There is no decompression step that recovers them.

AVIF also supports a lossless mode where quantization is bypassed. Lossless AVIF preserves all pixel values like PNG does. In practice, lossless AVIF is not yet competitive with lossless PNG on most image types — PNG's DEFLATE pipeline is more mature for typical screen content. The interesting use case for AVIF is lossy compression of photographs and web graphics, not lossless storage of diagrams.

A common source of confusion: you convert a 300 KB AVIF to PNG and get a 4 MB file. The tool is not broken. This is the expected and correct behavior, and the mechanism is straightforward.

The AVIF was 300 KB because it used lossy compression: the encoder discarded imperceptible pixel information to achieve that size. When a decoder opens the AVIF, it reconstructs approximately 12–24 million pixel values (for a typical photograph) into memory. PNG must then store all of those pixel values losslessly. The PNG file size reflects the amount of image data, not the AVIF file size. A 12-megapixel photo decoded to 8-bit RGB produces roughly 36 MB of raw pixel data before any compression. PNG's lossless DEFLATE can compress that to somewhere between 3 MB and 15 MB depending on image content. The AVIF was small because it threw away information; PNG refuses to throw away information, so it stores what remains.

The reverse conversion also behaves as expected. A 5 MB PNG converted to AVIF might produce a 400 KB file. The AVIF encoder discarded some pixel accuracy to achieve that size. If you then convert the AVIF back to PNG, you will not get the original 5 MB PNG back — you will get a PNG of the lossy AVIF, which may be 3 MB (slightly smaller because some pixel variance was removed). This round-trip is destructive. See the AVIF to PNG converter for a browser-based tool that handles this conversion without uploading your files.

Both AVIF and PNG support full alpha transparency, including partial transparency (values between fully transparent and fully opaque). This is worth stating clearly because JPG supports neither — a JPG has no alpha channel, and any transparent region becomes a solid color when saved to JPG. If your workflow involves images with transparent backgrounds, both AVIF and PNG are valid; JPG is not.

PNG's alpha channel has been a reliable part of the format since 1996. Every image editor, every browser, every design tool, and every print workflow that claims PNG support handles alpha correctly. The specification allows both 8-bit alpha (256 levels of transparency) and 16-bit alpha (65,536 levels). 8-bit alpha is more than sufficient for the vast majority of use cases; 16-bit PNG is mainly relevant in high-end compositing workflows.

AVIF supports alpha through an auxiliary image item in the ISOBMFF container. The alpha channel can be encoded losslessly even when the color data is encoded lossily, which is a practical advantage: sharp transparency edges (like logo cutouts) are preserved exactly while the color fill compresses efficiently. The downside is software support. Older versions of Photoshop, GIMP before 2.10.34, many DAM (digital asset management) platforms, most RIP (raster image processor) workflows for print, and embedded software in smart TVs or kiosk systems may decode the color plane but silently ignore the alpha plane, producing a solid-background version of the image. If your alpha channel must work reliably in software you do not control, PNG is the safer choice.

For web delivery of transparent images to modern browsers, AVIF's alpha works correctly in Chrome 85+, Firefox 93+, and Safari 16+. Using the HTML picture element with an AVIF source and a PNG fallback covers older browsers while serving the smaller AVIF to supported ones.

PNG's specification allows 8-bit and 16-bit per channel. In practice, almost all PNGs in circulation are 8-bit, meaning 256 possible values per channel (red, green, blue). That gives 256 × 256 × 256 = 16,777,216 possible colours. For SDR content on a standard display, 8-bit per channel is sufficient and indistinguishable from higher bit depths.

AVIF natively supports 8-bit, 10-bit, and 12-bit colour depth. At 10-bit, each channel has 1,024 possible values instead of 256. At 12-bit, each channel has 4,096 values. AVIF also supports HDR transfer functions — PQ (Perceptual Quantizer, used in HDR10) and HLG (Hybrid Log-Gamma, used in broadcast HDR). This combination of deep colour and HDR encoding means AVIF can carry high-dynamic-range image content that PNG cannot represent at all in its standard form.

When you convert an HDR AVIF to PNG, the tone-mapping step matters enormously. An HDR AVIF encoded with PQ transfer has highlights encoded far above the standard 100 nit SDR ceiling. A naive conversion to 8-bit SDR PNG clips or crushes those highlights. A proper conversion applies a tone-mapping operator (or a simple transfer function change from PQ to sRGB gamma) before writing the PNG. The result is a correctly exposed SDR image, but the HDR luminance range has been irreversibly discarded. The PNG you get back is not a lossless copy of the AVIF — it is a tone-mapped SDR version.

The quantization relationship is worth understanding: 8-bit gives 256 steps per channel (2 to the power of 8). Each additional bit doubles the number of steps. 10-bit gives 1,024 steps; 12-bit gives 4,096. When an HDR AVIF with 10-bit depth is converted to 8-bit PNG, the encoder divides the 1,024-step range into 256 buckets by integer division, discarding the two least significant bits of precision. Smooth gradients in the original may develop visible stepping (banding) in the PNG if the gradient spans a narrow value range that gets further quantized.

PNG support is as close to universal as any image format gets. Every web browser since the mid-1990s renders PNG. Every operating system includes PNG codecs in its image framework. Every professional image editor (Photoshop, GIMP, Affinity Photo, Lightroom, Capture One) reads and writes PNG. Every print workflow and RIP supports PNG. Every CMS, every email client, every office suite handles PNG. If you need an image to open on an unknown computer by an unknown person using unknown software, PNG is the safest format available.

AVIF support has grown substantially since 2020 but remains incomplete in several critical areas:

• Browsers: Chrome 85+, Firefox 93+, Safari 16.1+, Edge (Chromium-based) — broadly supported for web delivery.
• Photoshop: Native AVIF support from version 26.8 (June 2025). Earlier versions require a plugin or conversion.
• GIMP: AVIF read/write support from version 2.10.34 via the libavif loader. Older GIMP versions cannot open AVIF.
• Windows Explorer: Thumbnails and preview on Windows 11 natively; Windows 10 requires the free AV1 Video Extension from the Microsoft Store.
• macOS Preview: Reads AVIF from macOS Ventura (13) onwards.
• Print workflows: Most RIP software does not support AVIF. Convert to TIFF or PDF for print delivery.
• Email clients: Outlook, Apple Mail, and Gmail web do not reliably render AVIF inline. Use PNG or JPG for email images.

The bottom line: use AVIF when you control the delivery environment (your own website, CDN, modern app). Use PNG when the image leaves your control and must open reliably in any software.

Converting AVIF to PNG makes sense in a specific set of situations where lossless storage or broad software compatibility is more important than file size:

• You need to edit the image in software that does not open AVIF — older Photoshop, most print RIPs, legacy DAM systems.
• You are sending the image to a printer, print-on-demand service, or production house. Print workflows expect TIFF or high-quality PNG, not AVIF.
• You are creating a favicon, app icon, or UI asset. Icon pipelines (Xcode asset catalogs, Android drawables, Windows .ico workflows) all handle PNG natively.
• You need the alpha channel to work reliably in environments you do not control, such as a third-party platform or a client's legacy system.
• You want a lossless working copy to make further edits without stacking additional lossy generations. Convert to PNG (or better, TIFF) and edit from there.
• You are archiving a master copy that must be openable by anyone using any tool in the future.

Use the AVIF to PNG converter to do this conversion locally in your browser — your files are never uploaded to a server. You can also use the online AVIF to JPG converter if you need a smaller file for sharing rather than editing.

There are situations where converting AVIF to PNG is a clear mistake and will actively harm your workflow:

• Web delivery. If your goal is displaying the image on a website, keeping it as AVIF is almost always better. A 400 KB AVIF becoming a 5 MB PNG to serve on a webpage is a significant performance regression. Use AVIF directly with a JPG or WebP fallback via the HTML picture element.
• Storage when size matters. If you have a large archive of AVIF images from a camera or drone that supports AVIF output, converting the entire archive to PNG will multiply your storage requirements substantially for no quality benefit (the information the AVIF encoder discarded is gone — the PNG just stores what remains losslessly).
• When you expect lossless fidelity to the original scene. AVIF is a lossy format. Converting it to PNG does not recover the pixel data the AVIF encoder discarded. The resulting PNG is a lossless copy of the lossy AVIF, not a lossless copy of the original scene. If lossless original-quality storage is the goal, shoot in RAW or capture a lossless TIFF at source.
• Passing through an intermediate PNG to reach a final JPG. If your actual goal is a JPG — for email, for social sharing — convert AVIF directly to JPG rather than AVIF → PNG → JPG. The extra PNG step adds a large temporary file and an extra encode step with no benefit.

A useful rule: PNG is a working format, not a delivery format. Reach for it when you are editing, archiving, or sending to print. For web delivery, stay in AVIF. For broad sharing, use JPG. The AVIF to JPG conversion guide covers the sharing use case in detail.

For batch workflows or automated pipelines, both ffmpeg and ImageMagick handle AVIF-to-PNG conversion. These tools require libavif or dav1d to be linked at compile time for AVIF decoding.

Convert a single AVIF to PNG with ffmpeg:

ffmpeg -i input.avif output.png

Convert with ImageMagick (Magick v7):

magick input.avif output.png

Batch convert a directory of AVIF files to PNG with ffmpeg in a shell loop:

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

To go the other direction and encode a PNG as AVIF using avifenc (from libavif):

avifenc --min 24 --max 32 --speed 6 input.png output.avif

The --min and --max parameters control the quantizer range (lower numbers = better quality, larger file). A range of 24–32 is a practical balance for web delivery. The --speed flag (0 = slowest/best compression, 10 = fastest/worst) at 6 gives reasonable encoding speed without sacrificing too much compression efficiency. Check ffmpeg AVIF support with ffmpeg -codecs | grep avif before running these commands. If you see no result, your ffmpeg build was compiled without AVIF support and you will need to install a version that includes it or use the browser-based tool at open AVIF file instead.

The choice between AVIF and PNG comes down to four questions:

• Does the image need to open in software you do not control? If yes, PNG is safer. AVIF still has gaps in older Photoshop, print RIPs, email clients, and legacy DAM tools.
• Is this going on a website where you can verify browser support? If yes, AVIF will be smaller and faster. Pair it with a PNG or JPG fallback for older browsers using the picture element.
• Does pixel-perfect fidelity matter? If yes and the image has never been lossy-compressed, use PNG to preserve every value. If the source was already an AVIF (lossy), converting to PNG gives you a lossless copy of the lossy result, not a lossless original.
• Is this going to print? Convert to PNG (or TIFF) first. Most print RIPs do not decode AVIF, and PNG is universally accepted.

For a longer comparison that includes JPG alongside these two formats, the guide to opening AVIF files covers the full software compatibility picture in one place.