Image Compression Efficiency, and Why AVIF Wins

JPEG was standardized in 1992. It is still the default image format on most of the web. That is a long time to go without a meaningful replacement, and the cost shows up every time a user loads a page on a slow connection or a browser renders an image on a high-density display.

The core problem with JPEG is not that it is bad. It was designed for hardware and bandwidth constraints that no longer exist, and the compression tools it uses have not aged well. DCT on 8x8 pixel blocks produces the characteristic blocking and ringing artifacts that become visible as file size decreases. JPEG has no alpha channel. It is limited to 8-bit color. On high-DPI screens, where you are already serving 2x or 3x resolution images, those limitations compound.

You are paying a file size premium for a format that still produces visible artifacts.

WebP was not enough

Google introduced WebP around 2010 as a JPEG replacement. It is based on VP8 intra-frame coding and offers better compression with lossless and alpha support. It helped. But WebP only supports 4:2:0 chroma subsampling, which halves the color sample count and introduces color bleeding around hard edges. That matters most for UI artwork, logos, and text-over-image compositions where hard color transitions are common. For photographic content it is fine. For the kind of images that appear in a product UI, the chroma limitations are a real problem.

WebP also has no HDR support and no 10-bit depth, which makes it a dead end for the direction displays and content are heading.

What AVIF actually is

AVIF is the AV1 Image File Format. It takes the intra-frame coding tools from AV1, the open, royalty-free video codec developed by the Alliance for Open Media, and packages them as a still image format.

AV1 was built to replace HEVC and VP9 for video. Its compression tools are significantly more advanced than what JPEG or WebP use. Applying those tools to images produces a format that is better in almost every dimension:

  • 4:2:0, 4:2:2, and 4:4:4 chroma subsampling with no forced quality tradeoff for UI images
  • 8-bit and 10-bit color depth
  • Lossless compression
  • Alpha channel
  • Wide color gamut and HDR metadata
  • Animated image sequences, a proper GIF replacement

The feature set is not incremental. It is a different class of format.

The compression numbers

The Netflix engineering team published a detailed benchmark in 2020 comparing AVIF against JPEG, WebP, HEVC, and JPEG 2000 across their own internal datasets: boxshots, billboard artwork, and publicly available datasets including Kodak and CLIC.

The results are consistent: AVIF delivers the same perceptual quality as JPEG at roughly 40 to 50 percent smaller file sizes.

One result from their boxshot dataset (1142x1600 resolution UI artwork, the kind of image-heavy interface Netflix runs on every device): JPEG at 69,445 bytes showed severe banding, blocking, and color distortion. AVIF at 40,811 bytes, 29 kilobytes smaller, looked significantly cleaner. At a slightly higher budget, AVIF at 85,162 bytes was nearly indistinguishable from the source while JPEG at 80,101 bytes still had visible banding.

This is not a cherry-picked edge case. The BD-rate results across their datasets show AVIF consistently outperforming JPEG by a wide margin on every quality metric they tested: SSIM, MS-SSIM, VIF, and PSNR.

The full analysis, methodology, and open-source benchmarking framework are in the Netflix Engineering article.

Browser support

At the time of the Netflix article in 2020, AVIF was just arriving in Chrome. That is no longer a concern. As of 2026, AVIF has full support in Chrome, Firefox, Safari, and Edge. The caniuse baseline covers all modern browsers.

The only real compatibility question is whether you need to support legacy browsers. The standard answer is a <picture> element with an AVIF source and a JPEG fallback.

<picture>
  <source srcset="image.avif" type="image/avif" />
  <img src="image.fallback.jpg" alt="..." />
</picture>

Browsers that support AVIF use the first source. Everything else falls through to JPEG. There is no JavaScript involved and no runtime cost.

Encoding

Most image processing tools support AVIF now. Sharp handles it in Node.js. Squoosh encodes it in the browser. ImageMagick, FFmpeg, and libavif all work from the command line.

The one real tradeoff is encoding speed. AVIF encoding is slower than JPEG, meaningfully so at the higher quality presets. For build-time image pipelines this is usually acceptable. For anything user-generated or real-time, encoding quality settings matter and you may need to benchmark what is fast enough for your use case.

Decoding is fast. The performance cost is in encoding, not in what users experience.

For new projects, the default should be AVIF with a JPEG fallback. The file size savings are real, the quality is better, and the browser support is there.