What Determines AVIF File Size

AVIF is a lossy format by default, which means the encoder discards pixel data that it judges to be imperceptible. How aggressively it discards is controlled by a quality parameter. In libavif — the reference encoder — this is expressed as a “constant quality” (CQ) value. Lower CQ means the encoder is allowed to discard less, which preserves more detail and produces a larger file. Higher CQ means more aggressive discarding, smaller files, and eventually visible blur or banding.

Think of this knob as the single biggest lever you have over AVIF file size. Moving it a few steps in either direction can double or halve the output byte count while holding resolution constant. The tricky part is that the same CQ value produces different file sizes for different images, because how much data the encoder can discard depends entirely on what the image contains. A flat blue sky compresses to almost nothing; a close-up of a tabby cat's fur at the same CQ will be several times larger.

Other encoders — ffmpeg, Squoosh, Sharp — expose the same idea under slightly different names (quality, crf, q). They are all adjusting the same fundamental trade-off between perceptual fidelity and byte count. The right setting is always “as high as your use case can tolerate before the image looks wrong,” not a fixed number pulled from a guide.

Pixel count is the most straightforward driver of file size. Double the width and height of an image and you quadruple the number of pixels the encoder must process. File size does not grow at a perfectly 4x ratio — compression efficiency varies — but the relationship is strongly super-linear. A 6000 × 4000 photograph will be dramatically larger than the same scene at 1500 × 1000 even at the same CQ value.

High-resolution images also tend to contain more high-frequency detail simply because there are more pixels to encode fine-grained textures. This compounds the size effect: you pay once for the raw pixel count and again for the detail density those pixels carry. A phone camera shot at full 48 MP resolution has both problems simultaneously.

The practical implication is straightforward: always resize to your display dimensions before encoding. Serving a 4000 px wide hero image to a viewport that renders it at 1200 px wide wastes bytes unconditionally — the extra pixels are discarded by the browser and never seen. Resize first, encode second, and the quality knob can stay at a higher-fidelity position for the same total file size. Tools like AVIF-to-JPG converters that accept a target resolution can handle both steps in one pass.

Compression works by finding and exploiting patterns. A block of pixels that are all the same shade of blue can be described in far fewer bytes than a block where every pixel is a different color. The amount of unpredictability in an image is called its entropy, and it is probably the most under-appreciated factor in AVIF file size.

Low-entropy content — flat UI screenshots, product photos on white backgrounds, logos, solid-color gradients — compresses extremely well in AVIF. The encoder finds large regions of near-identical pixels and describes them with very few bits. High-entropy content — photographs of tree canopies, close-ups of fabric weaves, gravel paths, fur, or any fine repetitive texture — is close to random at the pixel level. The encoder cannot predict adjacent pixels reliably, so it must store more data per pixel to reconstruct the scene at the same quality level.

This is why two images at the same resolution and same CQ setting can differ in file size by an order of magnitude. The quality knob only controls how much information the encoder is allowed to throw away; entropy determines how much information was there to begin with. If you are surprised by a large AVIF output, the content is almost certainly high-entropy — try lowering your quality expectations slightly or cropping to the key subject before encoding.

AVIF, like most compressed image formats, separates luminance (brightness) from chrominance (color). Human vision is far more sensitive to brightness variation than to color variation, so encoders routinely store the color channels at a lower resolution than the brightness channel. This is called chroma subsampling.

The most common setting is 4:2:0, where the two color channels are stored at half the width and half the height of the full image. This cuts the color data to one-quarter of what it would be at full resolution, with minimal visible impact for photographic content. Most web-optimized AVIF encoders default to 4:2:0 for this reason. The alternative, 4:4:4, stores full-resolution color data and produces larger files — it is worth using for images where color fidelity at sharp edges matters, such as text overlaid on colored backgrounds or fine line art.

Bit depth is a related lever. AVIF supports 8-bit, 10-bit, and 12-bit color per channel. Moving from 8-bit (256 steps per channel) to 10-bit (1,024 steps per channel) gives noticeably smoother gradients and eliminates color banding in skies and skin tones. But more bits means more data to store. If your source image was captured in 8-bit and the display is 8-bit, encoding to 10-bit buys nothing and costs file size. Match bit depth to what your source and display pipeline actually need.

AVIF supports full alpha transparency — a separate channel that encodes which pixels are opaque, semi-transparent, or fully transparent. Alpha is stored as an independent image plane alongside the color data, which means adding transparency to an image essentially adds a second grayscale image to the file.

For simple logos or icons where the alpha channel is mostly binary (fully opaque or fully transparent), the overhead is small because the channel itself has low entropy. For images with complex, smooth transparency gradients — a product photograph with a soft-edge cutout, a frosted glass UI element, a blurred shadow mask — the alpha channel can add meaningfully to the file size.

If you are converting AVIF to a format that does not support transparency, the alpha channel is merged against a background color (usually white) during conversion. Tools like the AVIF-to-PNG converter preserve the alpha channel because PNG supports it natively. The AVIF-to-JPG converter flattens transparency to a solid background, since JPG has no alpha channel. If you do not actually need transparency in your final output, stripping the alpha plane before encoding is a free size reduction.

Film grain and sensor noise are a specific type of high-entropy content that AVIF handles with a clever technique not found in older formats. Instead of encoding every grain pixel individually — which would require a huge amount of data for essentially random variation — the AV1 codec can strip the grain from the source image during encoding, store just a compact mathematical description of the grain's statistical properties (grain synthesis parameters), and then regenerate perceptually identical noise at decode time.

The result is an AVIF that looks like it contains film grain, but achieves significantly smaller file sizes on grain-heavy content than a naive encoding would. The underlying image without grain is much lower entropy, so the encoder can compress it far more efficiently. This is one of the features that makes AVIF particularly well-suited for cinematic or analog-aesthetic photography where preserving the grain feel matters.

Film grain synthesis is controlled by a separate encoder flag (for example, --filmgrain in some avifenc builds). It is not the default, and not every AVIF encoder exposes it. If you are encoding photographs from a film camera or any source with strong consistent noise, it is worth experimenting with.

A frequent source of confusion: you take an AVIF file, convert it to PNG, and the PNG is five or ten times larger. This is not a bug. PNG uses lossless compression — every pixel in the output matches the decoded pixel exactly. When you decode a lossy AVIF, the decoded pixel values are the result of the encoding process: some detail has been removed, but there is still a full grid of pixel values. PNG then stores all of those values without discarding anything further. DEFLATE (the compression inside PNG) is efficient for patterns and runs, but photographs are high-entropy and compress poorly in a lossless encoder.

Converting AVIF to JPG produces a smaller file, but only because JPG applies another round of lossy compression. The file gets smaller because information is discarded again. This is never free — you are stacking two generations of lossy encoding, and each generation amplifies the artifacts of the previous one. If you need a small JPG from an AVIF source, set the JPG quality parameter deliberately. A high JPG quality setting (90–95) stays close to the AVIF's decoded quality. A low setting (60–70) will be small but noticeably degraded, because the encoder is quantizing data that was already quantized.

The same logic applies in reverse: if you convert a PNG to AVIF, the AVIF will almost always be much smaller than the PNG, because the AVIF encoder is allowed to discard imperceptible data. Visit the AVIF vs JPG comparison for a deeper look at what gets lost in each direction.

Most file size problems come down to a short list of fixable decisions made before or during encoding. Here are the most effective interventions, roughly in order of impact:

• Resize to display dimensions first. Encoding a 4000 px image for a 1200 px slot wastes more than half the bytes unconditionally. Always scale to the largest size it will actually be rendered at before encoding. The command-line tools that open and re-encode AVIF files can handle the resize step inline.
• Raise the CQ / lower the quality until the image looks acceptable. Most images tolerate more compression than you expect. View the output at 100% zoom on the target device before deciding whether you need to push the quality back up.
• Remove the alpha channel if transparency is not needed. Stripping an unused alpha plane is a zero-cost size reduction. If the image is already opaque, encode it as RGB rather than RGBA.
• Use 4:2:0 chroma subsampling for photographs. For photographic content the color resolution loss is imperceptible in almost all viewing conditions. Reserve 4:4:4 for text, line art, or UI elements where color fringing would be visible.
• Avoid re-encoding chains. Each round of lossy compression stacks degradation. If you must produce multiple output formats, generate them all from the same lossless or high-quality master rather than re-encoding an already-compressed file.
• Use avifenc or ffmpeg with explicit settings. Batch conversion with default settings often uses conservative quality values. Explicitly setting the quality and chroma subsampling gives predictable, repeatable output.

A basic ffmpeg command that applies explicit settings looks like this:

ffmpeg -i input.avif -c:v libaom-av1 -crf 30 -b:v 0 output.avif

Or with avifenc directly, which gives finer control over the quality scale:

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

If you need to convert AVIF files to JPG or PNG for broader compatibility, the online AVIF converter handles the process in the browser without uploading your files to any server.

One of the most counterintuitive properties of lossy compression is that running it twice on the same image produces something worse than either single pass, not the same as either. Converting a lossy AVIF to PNG and then re-encoding that PNG back to AVIF does not return you to the original AVIF. It produces a new AVIF that is larger and blurrier than the first one, because the second encoder is working on data that has already been through a quantization pass.

The mechanism is simple: lossy compression introduces artifacts — slight blurs, mild ringing, subtle color shifts. These artifacts exist as actual pixel values in the decoded output. When you feed that decoded output into a second lossy encoder, the encoder treats the artifacts as real image content that must be faithfully reproduced. It then adds its own quantization error on top. The artifacts compound. The file size does not decrease proportionally because the second encoder now has to preserve two layers of compression noise.

The practical rule is simple: never use a compressed image as the source for re-compression unless you are explicitly accepting quality loss. Always keep the original lossless source file — the RAW, TIFF, or lossless PNG — and generate all compressed derivatives from that master. If the only file you have is a compressed AVIF and you need a JPG, convert it once at a high quality setting and treat the result as a terminal output, not a re-encodable intermediate.