AVIF stands for AV1 Image File Format, not “another video-based image format.” The format was derived from AV1, a royalty-free video coding format, hence the sneaky reference in the title.

The term “another” appears in the title as a reference to WebP, an image format that was created from the VP8 video coding format as well as BPG and HEIC, both of which were derived from the HEVC video codec.

What is AVIF?

AVIF is a widely supported, compression efficient encoding format that supports lossy and lossless compression. It yields better quality images at smaller file sizes when compared with JPEG or WebP. We’ll look at the history, the capabilities, and use-cases where AVIF might not be the best fit.

At the time of writing, AVIF images are supported in roughly 64% of all browsers, as per caniuse.com. Chrome has full support along with Opera; Edge, Firefox* and Safari do not. (*You can flip the image.avif.enabled flag under about:config. Plans exist to enable AVIF support from Firefox 92 by default.) We’ll look at ways to use AVIF today with a fallback, regardless of browser.

History

AVIF was created by the Alliance for Open Media (AOM), which built a royalty-free video format called AV1. To create a new video format, you need an image codec that encodes the keyframes. Once the video format shipped, packaging up and open-sourcing the image codec was a no-brainer.

Is AVIF worth it?

Short answer: yes. AVIF outperforms all other image formats currently used on the web, including WebP, which for a long time was considered the most efficient option available.

Let’s look at some specific comparisons. When comparing images, there are two accepted approaches: size comparison and quality comparison. For size comparison, you generate images of equal file size (say, a 25kb JPEG, WebP and AVIF) and observe visual deficiencies, determining which yields higher quality at a given size. The other method involves reducing quality and comparing the resulting file sizes.

Take a look at the example below. The first table compares sizes at the same quality reduction. At “quality 50” the smallest file size belongs to AVIF:

original (JPG)	293 283 B
JPG (q50)	94 398 B
WebP (q50)	98 388 B
AVIF (q50)	79 026 B

But does that mean the AVIF is also closest to the original in terms of similarity? For this test, we’ll use SSIMULACRA, a tool that produces a perceptual metric designed specifically for scoring image compression artefacts in a way that correlates well with human opinions. (Read more about SSIMULACRA). The closer the number is to 0, the fewer visual defects on a given image. (Ideally the value should sit between 0 and 0.1, where 0 means a 100% match to the original.)

original (JPG)	0
JPG (144 kb)	0.03666286
WebP (146 kb)	0.03067365
AVIF (146 kb)	0.02372729

AVIF wins again.

There are some cases when AVIF may not be the best option, please refer to this amazing article from Jake to learn more.

Drawbacks

We’ve covered the positives. Now let’s look at specific scenarios where AVIF might not be the best choice.

Encoding speed

Encoding large images to AVIF takes longer compared to its competitors; decoding, however, shows no noticeable delays. You could establish rules in your image processing pipeline, specifying that images under certain sizes or dimensions get converted to AVIF to avoid adding processing delays.

Progressive rendering

Progressive rendering isn’t available in AVIF. (There are workarounds involving a blurred placeholder version of the image.) Browsers can’t display parts of an AVIF image progressively. The video below compares a progressive JPEG next to an AVIF to show the difference. (Recorded in Chrome, both images loaded at a throttled “Fast 3G” connection.)

Perceived sharpness

Due to how AVIF encodes images, some detail can be lost, and perceived sharpness deteriorates. Because of this, AVIF isn’t recommended for images where users are expected to zoom in heavily. The example below shows a product image zoomed in, revealing several visual deficiencies from the encoding.

Best practice: use avif mostly for low-fidelity high-appeal compression (no noticeable artefacts, though subtle things like textile textures can be erased). Stick to (moz)jpeg for now (at least until jxl lands in browsers*) for high-fidelity use-cases like high-end e-commerce product pages.

Please note that jxl is currently supported behind a flag in various browsers.

Notice that the JPEG version of the image is sharper than the AVIF version, where we can observe colour bleeding and blurriness.

Implement AVIF today

Browser support isn’t widespread for AVIF, but there are techniques you can use right now to display AVIF images.

The simplest technique is the picture element with a fallback source:

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

You can bolt on additional source elements for multiple fallbacks:

<picture>
  <source type="image/avif" srcset="madrid.avif" />
  <source type="image/webp" srcset="madrid.webp" />
  <img src="madrid.jpg" />
</picture>

Browsers interpret the above like so: if AVIF is supported, the <source> element gets displayed; otherwise, it falls back to the <img> element.

Another option is an Image CDN like Cloudinary with the f_auto flag, which determines the best format to serve based on the image and the browser. You can also explicitly request AVIF using the f_avif flag. (This will try to render AVIF regardless of browser support, so use it with caution.)

Conclusion

Bearing in mind the drawbacks outlined above, you can assess whether AVIF is the right format for your images. Using HTML’s <picture> element or an Image CDN, you can serve them to all supporting browsers. AVIF can cut the bandwidth consumed, but it may introduce longer processing times in your image optimisation pipeline and visual artefacts for particular images.