Before you get carried away and feel a temptation to correct me, let's establish that AVIF stands for AV1 Image File Format and not "another video-based image format". The format, though, was derived from AV1, a royalty-free video coding format, and that's why you see that sneaky reference in the post's title.
The term "another" appears in the title as a reference to
WebP, an image format that was created from theVP8video coding format as well asBPGandHEIC, both of which were derived from theHEVCvideo codec.
The "official" definition is that AVIF is a widely supported, compression efficient encoding format that supports lossy and lossless compression. Generally speaking, AVIF would yield better quality images at smaller file sizes when compared with JPEG or WebP. In this article, we'll look at the history, the capabilities of AVIF, and use-cases where AVIF may not be the best option.
Please note that at the time of writing this article, AVIF images are supported in roughly 64% of all browsers, as per caniuse.com. Chrome has full support along with Opera, however Edge, Firefox* and Safari do not support this file format. (*You can enable support in Firefox by setting the image.avif.enabled flag under about:config There are also plans on enabling AVIF support from Firefox 92 by default). We will take a look at ways that you can use AVIF today with a fallback, regardless of the browser.
AVIF was created by the Alliance for Open Media (AOM), which made a royalty-free video format (called AV1). As it turns out, to create a new video format, you need to create an image codec that encodes the keyframes. Once the video format was created, packaging up and open-sourcing the image codec was a no brainer.
The short answer is yes. What's fantastic about AVIF is that, in general, it outperforms all other image formats used currently on the web, including WebP - which, for a long time, has been considered to be the most efficient image format on the web.
Let's take a look at some specific examples and compare AVIF to other image formats. When it comes to comparing images, there are two accepted ways: size comparison and quality comparison. For the former, we generate images that are equal in size (for example, a 25kb JPEG, WebP and AVIF) and observe any visual deficiencies and try to determine which image yields a higher quality at a given size. The other comparison method involves a reduction in quality and comparing the file sizes of the resulting images; here, we would try to observe if specific quality reductions reduce the file size in a significant way.
Take a look at the example below. In the first table we are comparing the sizes of the images at the same quality reduction. Clearly, at "quality 50" the smallest filesize is produced by 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, that the AVIF is also the closest to the original in terms of similarity? For this test, we'll be using SSIMULACRA - a tool that produces a perceptual metric designed specifically for scoring image compression related artifacts in a way that correlates well with human opinions. (Read more about SSIMULACRA). Basically, the closer the number is to 0, the less visual defects are there on a given image. (ideally the "right" value should be anywhere between 0 - 0.1 where 0 signifies 100% match to the original image).
| original (JPG) | 0 |
|---|---|
| JPG (144 kb) | 0.03666286 |
| WebP (146 kb) | 0.03067365 |
| AVIF (146 kb) | 0.02372729 |
Clearly, 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.
We talked about all the positives of AVIF; however, there are specific scenarios and use-cases where it may not be the best choice.
Encoding large images to AVIF takes more time compared to its competitors; however, there are no noticeable delays when it comes to decoding the images. You could establish some rules in your image processing pipeline and specify that images under specific sizes or dimensions (width x height) would be converted to AVIF to avoid adding delays to your processing.
Progressive rendering is not available in AVIF. (Although there are some workarounds for this, which involve adding a blurred version of the image.). This means that browsers are not able to display parts of an AVIF image progressively. The video below contains a comparison of a progressive JPEG next to an AVIF to demonstrate the difference. (The video was recorded using Chrome, loading both images at a throttled, "Fast 3G" connection.)
Due to how AVIF encodes images, some detail may be lost; therefore, the perceived sharpness of the image can deteriorate. In light of this, it's not recommended to utilise AVIF for images where users are expected to zoom in heavily. The below example demonstrates where the product image is zoomed in, and we can observe several visual deficiencies resulting from the encoding.
Generally speaking, it's best to use avif mostly for low-fidelity high-appeal compression (as this would not create noticeable artifacts but subtle things like textile textures can be erased), and stick to (moz)jpeg for now (at least until jxl becomes a thing in browwsers*)) for the high-fidelity use-cases like high-end e-commerce product page images.
Please note that
jxlis 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 some colour bleeding and blurriness.
In the first section of this article, we established that browser support is not widespread for AVIF; however, there are specific techniques that you can employ to display AVIF images.
The most straightforward technique is the use of the picture element with a fallback source:
<picture>
<source type="image/avif" srcset="madrid.avif" />
<img src="madrid.jpg" />
</picture>You can add additional source elements to have multiple fallbacks, for example:
<picture>
<source type="image/avif" srcset="madrid.avif" />
<source type="image/webp" srcset="madrid.webp" />
<img src="madrid.jpg" />
</picture>The way browsers interpret the above HTML code is simple: if AVIF is supported, the <source> element will be displayed; otherwise, we fall back to displaying the content specified by the <img> element.
Another viable way would be to use an Image CDN, such as Cloudinary with the f_auto flag, which will determine the best format to serve based on the image and the browser. Or, if you wish to explicitly load an AVIF you can use the f_avif format setter flag. (Do not that this option will try to render an AVIF no matter what browser you are using, so use it with caution.)
Bearing in mind the drawbacks specified in this article, you can investigate whether AVIF would be the optimal format for your images. Using either HTML's <picture> element or an Image CDN, you can serve them up to all supporting browsers. Remember that with AVIF, you can reduce the bandwidth consumed, but you can introduce longer processing times in your image optimisation pipeline and visual artefacts for particular images.