Lossless AVIF, Explained

AVIF is built on AV1, a video codec developed by the Alliance for Open Media. AV1 supports both lossy and lossless intra-frame encoding, and because AVIF inherits that codec, it can produce files where every source pixel is reproduced exactly. In encoder terms, lossless mode bypasses the quantizer entirely and routes the data through a dedicated entropy coding path. The result is mathematically identical to the input.

Despite being technically available, lossless AVIF is uncommon in practice. Most AVIF workflows — web delivery, image optimization pipelines, CDN transcoding — use the lossy mode with a quality parameter tuned for visual fidelity. The lossless path exists primarily because AV1 was designed as a full-featured video codec and lossless encoding was part of the spec. It was not added with still-image archival as the primary use case, which has consequences for file size and performance that we will cover in the sections below.

Understanding when lossless AVIF helps — and when it works against you — requires understanding what “lossless” means in this context, how the encoder achieves it, and what trade-offs come with that choice compared to PNG, the dominant lossless format on the web and in design workflows.

In a lossy AV1 encode, the encoder divides the image into blocks, predicts each block from neighboring blocks, computes the residual (the difference between prediction and reality), transforms that residual with a DCT-like transform, and then quantizes the coefficients — rounding small values to zero to save bits. Quantization is where information is permanently discarded.

Lossless mode keeps every step except quantization. The prediction, transform, and entropy coding stages still run, but the residuals are encoded at full precision with no rounding. Because the prediction step can be quite accurate for smooth regions, lossless AV1 still achieves meaningful compression over raw pixel data. However, the prediction tools in AV1 were tuned for video content where temporal redundancy (frame-to-frame similarity) provides most of the compression budget. For a single still image, only the spatial prediction applies, and the efficiency advantage over PNG — which uses a simpler but purpose-built spatial filter — is often absent or reversed.

On the encoder side, you enable lossless mode explicitly. In libavif's avifenc tool, the flag is --lossless. You can also set --min 0 --max 0 to pin the quantizer range to zero. Without one of these explicit settings, avifenc defaults to lossy output, so there is no ambiguity if you know what to look for.

PNG's lossless compression works differently from AV1's. A PNG encoder first applies one of five row-by-row filters (none, sub, up, average, Paeth) to remove spatial redundancy, then compresses the filtered data with DEFLATE. This pipeline was designed from the ground up for two-dimensional pixel data, and it tends to handle the patterns common in still images — smooth gradients, repeated textures, large uniform regions — efficiently.

For photographs and typical web graphics, PNG is often smaller than lossless AVIF. AV1's prediction machinery carries overhead — block headers, mode signaling, transform coefficients — that adds up for images where a simpler predictor would have worked. The situation can vary by image content: lossless AVIF may occasionally beat PNG on images with specific spatial frequency patterns that AV1's directional intra prediction handles well, but this is not a reliable general-purpose advantage.

Encoding and decoding speed are also significantly different. Writing a PNG is fast; most encoders can produce a PNG in milliseconds for a typical web image. Encoding a lossless AVIF takes substantially longer because AV1's prediction search is more computationally intensive than PNG's filter selection. Decoding is similarly heavier for AVIF. For batch processing workflows or real-time image serving, these speed differences matter in practice.

A common mistake is assuming that setting the quality slider to its maximum value produces lossless output. In many encoders, “quality 100” means the smallest quantization step in the lossy range — visually near-perfect but not mathematically lossless. To guarantee pixel-exact output, you must use the explicit lossless flag.

With avifenc, the correct command is:

avifenc --lossless input.png output.avif

You can also add a speed setting. The --speed parameter in avifenc ranges from 0 (slowest, best compression) to 10 (fastest, worst compression). Speed 6 is a reasonable default. For lossless output, lower speeds can reduce file size by enabling more thorough prediction search, but the gains diminish past a certain point and the encoding time increases substantially.

avifenc --lossless --speed 4 input.png output.avif

Using ffmpeg with libavif support, you can pass -crf 0 to request lossless, but confirm your ffmpeg build links libavif and that the version is recent enough to support the lossless path correctly. Older builds had known issues in this area. Always verify lossless output by comparing a decoded pixel against the source rather than relying solely on encoder flags.

Even if a piece of software can open lossy AVIF, that does not mean it will handle lossless AVIF correctly. The lossless path exercises different decoder branches, and some implementations have bugs or gaps in that path while the lossy path works fine. In practice this means that a lossless AVIF may fail to open, open with incorrect colors, or trigger a decoder error in tools that display a lossy AVIF without complaint.

PNG has no such problem. Every image editing application, operating system viewer, browser, command-line tool, and content management system that has been written since the late 1990s can read a standard PNG. The format is documented, the specification is stable, and the decoder surface area is small enough that almost nothing breaks. When you share a PNG with a client, a print lab, or an unfamiliar software stack, you can be confident it will open correctly.

For lossless AVIF, the support picture is improving — Photoshop 26.8 added native AVIF support, Chrome and Firefox handle it correctly in the browser, and macOS Ventura added Preview support for AVIF — but the long tail of older software, embedded tools, and third-party applications makes lossless AVIF unreliable as a general-purpose interchange format. It works well within a controlled pipeline; it is a poor choice for anything that crosses a software boundary you do not own.

There is a narrow but real set of situations where lossless AVIF is the right choice. The clearest case is when you are operating a pipeline that already delivers AVIF exclusively and you need pixel-exact fidelity for one specific asset in that pipeline — for example, an image that must round-trip through a transformation without any quality degradation before being re-encoded for display.

The second case involves AVIF-specific capabilities that PNG cannot provide. PNG is limited to 8-bit per channel sRGB or 16-bit grayscale in common usage. AVIF supports 10-bit and 12-bit depth, HDR transfer functions (PQ and HLG), and wide-gamut color spaces. If you need to preserve an HDR or wide-gamut image without any lossy encoding step, lossless AVIF is currently the most practical container that combines those capabilities with reasonable browser support. PNG simply cannot store that information.

• Full-AVIF delivery pipeline needing pixel-exact intermediate files without switching formats.
• HDR or 12-bit wide-gamut images where PNG cannot represent the color data and you still need lossless preservation.
• Round-trip verification: if you need to confirm that an encode-decode cycle produces no pixel change, lossless AVIF gives you that guarantee while staying in the AVIF ecosystem.
• Research or tooling contexts where you want to measure lossy encoder artifacts by comparing against a lossless reference stored in the same format.

For the vast majority of lossless use cases, PNG is the better choice. It is smaller for most images, encodes and decodes faster, opens in every tool without special handling, and has no compatibility risks across software boundaries. The practical advice is straightforward: use PNG as your default lossless format and reach for lossless AVIF only when a specific constraint pushes you there.

• Editing masters and source files for design tools — Figma, Sketch, Affinity Photo, and Illustrator all import PNG natively.
• Files sent to clients, print labs, or stock libraries that may use older software or unknown pipelines.
• Favicons, icons, and UI assets where compatibility with every possible rendering environment matters more than cutting-edge compression.
• Any workflow where encoding speed matters, such as real-time screenshot capture or batch export from a video frame sequence.
• Images that will be opened by a mix of people on different platforms and operating systems where you cannot control the software stack.

If you are working with images that will eventually go to the web as AVIF or JPG for delivery, keeping the source as PNG and encoding to lossy AVIF at the serving layer is a cleaner architecture than lossless AVIF at every step. The lossy AVIF is what delivers the size savings; lossless AVIF in the middle of that chain adds complexity without benefit.

It is worth being clear about why AVIF has become popular: the format's size advantages over JPEG come almost entirely from lossy compression. At a given visual quality level, lossy AVIF produces smaller files than JPEG because AV1's prediction, transform, and entropy coding are more efficient than JPEG's 8x8 DCT pipeline. That efficiency gap is what makes AVIF worth adopting for web delivery.

Lossless AVIF does not participate in that story. If your goal is to reduce image bytes on a website, you want lossy AVIF at a well-chosen quality setting, not lossless AVIF. You can convert AVIF to JPG for maximum compatibility or keep AVIF for browsers that support it, but in either case the useful version is lossy. The lossless path is a specialized tool for a narrow set of pipeline requirements, not a general upgrade over PNG for everyday image storage.

One important consequence: converting a lossy AVIF to PNG does not recover the original image. The PNG will be lossless — every pixel it contains is preserved exactly — but those pixels already reflect the lossy encoding from the AVIF step. Detail discarded during lossy encoding is gone. If you need the original, you need the original source file, not a lossless re-encoding of a compressed version. For a straightforward AVIF to PNG conversion where pixel-exact fidelity to the original is not required, a standard browser-based converter works fine.

The choice between lossless AVIF, PNG, and lossy AVIF is simpler than it might appear once you know the trade-offs. Three questions cover most real-world decisions.

Do you need exact pixel preservation? If yes, you are in lossless territory. Within lossless options, default to PNG unless you specifically need HDR/wide-gamut/12-bit capabilities that PNG cannot store, or you are inside a controlled AVIF-only pipeline. If no, use lossy AVIF for web delivery (best compression) or lossy JPG for maximum compatibility with older software and non-browser destinations.

Does the file need to open everywhere? If the answer is yes — clients, print labs, email attachments, design tools on unknown versions — use PNG for lossless or convert to JPG for lossy. Both are universally supported. AVIF, lossless or lossy, is not yet safe to assume in every context outside modern web browsers.

Are you delivering to modern browsers and care about file size? Use lossy AVIF with a quality parameter tuned for your content type. This is where AVIF earns its place: real, consistent file-size reduction compared to JPEG at the same visual quality, with full support in Chrome 85+, Firefox 93+, and Safari 16+. Lossless mode is not part of this use case at all.

Comparing lossless formats requires a consistent method because file size varies significantly by image content. The most reliable approach is to test with your own images using a fixed encoder version, then record both compressed size and round-trip fidelity. A pixel comparison tool such as avifenc --lossless followed by a decode and diff against the original confirms whether the output is truly lossless before you count bytes.

For photographic content, PNG typically produces smaller files than lossless AVIF. In controlled comparisons using standard image corpora, lossless AVIF is often 10–30% larger than PNG for natural photographs. The gap narrows for computer-generated graphics with large flat regions, where AV1's intra prediction can find better structure to exploit, but PNG still wins more often than not. Lossless WebP sits in between: smaller than lossless AVIF on photographs in many cases, but not universally.

The practical test is straightforward. Take a representative sample of the images you actually work with — ten to twenty files that span your content types. Encode each to lossless AVIF and to PNG. Compare sizes. If PNG is consistently smaller, that resolves the question for your pipeline without needing to generalize. If AVIF comes out smaller on a particular image type, that is also a valid finding specific to your content. Benchmarks from other organizations are informative, but your image distribution is the only test that actually applies to your work.

One measurement pitfall: some encoders have a “lossless” mode that applies near-lossless quantization rather than true lossless encoding. If you are comparing sizes across encoders, verify each output by decoding and diffing against the source. A smaller “lossless” file that fails a pixel-exact check is not actually lossless, and the size comparison is not meaningful.

Lossless AVIF encoding is computationally expensive relative to PNG and JPEG. The AV1 codec was designed for video compression, where encoding time is amortized across many frames and hardware encoders are common. Repurposed for still images, the prediction search that gives AV1 its compression efficiency also makes encoding slow.

With avifenc, the --speed parameter controls how thoroughly the encoder searches for the best prediction mode at each block. Speed 0 performs an exhaustive search and produces the smallest file; speed 10 skips most of the search and encodes quickly but with a larger output. For lossless work, speed 4 to 6 is a practical range: encoding time stays within a few seconds per megapixel on modern hardware while leaving most of the compression benefit intact. Speed 0 and 1 can take a minute or more per image at high resolutions, with diminishing returns in file size beyond a certain point.

Tile settings also affect both speed and compatibility. Enabling tiling (--tiling) allows parallel encoding and can reduce wall-clock time, but some decoders have bugs with tiled lossless AVIF. If decoder compatibility is a concern, test with and without tiling using the target software before committing to a tile configuration. The--jobs flag controls how many CPU threads avifenc uses; setting it to the number of physical cores is a straightforward way to reduce encoding time without changing output quality.

Decoding speed is less of an issue for most use cases but matters for high-throughput pipelines. Lossless AVIF decoding is slower than PNG decoding, typically by a factor of two to five depending on image size and decoder implementation. If your pipeline decodes images in a hot path — a server that renders image previews on request, for example — PNG is likely the better choice for throughput, independent of file size.

JPEG does not support transparency. When converting a lossless AVIF that contains an alpha channel to JPG, the transparency information is dropped. What replaces the transparent areas depends on the converter: some fill with white, some fill with black, and some composite against a color you specify. If the output looks wrong around edges or object boundaries, the alpha channel handling is almost always the cause.

The correct approach is to composite the image against a background color before or during conversion. For web use, white is a common default. For images that will appear on a dark background, compositing against the actual background color before converting prevents light halos around anti-aliased edges. The converter on this page applies a white background fill by default; if you need a different background color, PNG is the better intermediate format — convert AVIF to PNG first, then composite and re-encode.

Color space handling is a separate concern. AVIF supports wide color gamut (Rec. 2020) and HDR metadata. JPEG is limited to sRGB in practice. When converting a lossless AVIF with a wide-gamut color profile to JPG, colors outside the sRGB gamut will be clipped or mapped, which changes their appearance. For photographic content from standard cameras, this is usually not a problem because the source is already sRGB. For images from professional cameras with wide-gamut profiles, or graphics created in a wide-gamut workspace, gamut clipping can shift colors noticeably in saturated areas.

JPEG also uses 8 bits per channel. Lossless AVIF supports 10-bit and 12-bit depth. A conversion from 10-bit or 12-bit lossless AVIF to 8-bit JPG reduces tonal depth, which can introduce banding in gradients. For most web images this is not visible, but for images used in print preparation or professional editing workflows, the bit depth reduction is worth noting before choosing JPG as the output format.