AVIF is a new image format for the web. Before I tell you all about it, let me show you what AVIF can do.
One way to compare image codecs is to encode the same image in different formats at matched file sizes and then compare the visual quality of the resulting images. For example, I rendered the AVIF below with a
q_50 quality transformation. It weighs 12.3 KB and, compared to the lossless original it looks pretty good subjectively.
- File size
- 12.3 KB
- File size
- 12.5 KB
- File size
- 12.3 KB
Photo credit: Aloïs Moubax
My favorite image-quality metric is SSIMULACRA. Lower scores are better; 0.01 is just about perfect and 0.1 is awful. SSIMULACRA gives the AVIF a score of 0.026, compared to the original. Pretty good!
I then rendered a WebP and a JPEG at the same file size. They look worse. SSIMULACRA gives the WebP a 41%-worse score than the AVIF; it gives the JPEG a 70%-worse score than the AVIF. Those numbers agree with my subjective judgement: the AVIF looks good; the WebP is borderline; and the JPEG is so full of artifacts that it’s unusable. All for the same 12.3 KB cost. Without question, AVIF gives you more bang for your byte.
Another good way to compare codecs is to render an image at a fixed quality and then compare the resulting file sizes. Here’s an example:
- File size
- 64.7 KB
- File size
- 48.6 KB
- File size
- 31.6 KB
Image credit: Studio Ghibli, “Spirited Away”
After rendering all three images with
q_auto, I saw that their SSIMULACRA scores were all in the same ballpark. And they all look fantastic when presented at 2x, more or less indistinguishable from the original.
The file size differences are stark, however. The WebP is 25% smaller than the JPEG, which is impressive enough, until you see that the AVIF is half the size of the JPEG.
In Cloudinary’s initial tests, AVIF typically compresses more efficiently than JPEG by around 50%. Converting to AVIF with Cloudinary only involves adding the
f_avif transformation parameter to your URLs. We’ve supported AVIF since it first shipped in a browser—in Chrome last August—and have been improving our implementation ever since.
Want to know more? Read on.
AVIF originated from the AV1 video codec. Here’s the background:
The patent minefields surrounding MPEG’s H.265 codec (aka HEVC) drove the world’s top tech companies to form a consortium called the Alliance for Open Media to come up with a royalty-free-forever alternative. And lo, in 2018, the AOM released the AV1 video format.
To build a next-gen video codec, one of the things you must do is create a next-gen image codec to encode the key frames. And, as long as you already have an image codec that handily outperforms the status quo just kicking around inside your video codec, it’s not too much trouble to split it off, wrap it up, and release it as a stand-alone image format.
That was what Google did with VP8 when the company created WebP. Similarly, iPhones now capture and store images with High Efficiency Image File Format (HEIF) containers around HEVC keyframe payloads, aka HEIC files.
A few of the companies behind AV1 came up with the idea to use the HEIF container with AV1 keyframe payloads, thus creating the AV1 Image File Format (AVIF for short).
Just about everything!
Deciding which format to adopt for a given image on the Internet used to be pretty complicated. You had to determine whether the image contained any transparency (which ruled out JPEG), and whether its content was “photographic” (with continuous tones and fuzzy edges, in which case JPEG or WebP would be your answer). If the image contained lots of sharp edges and flat colors instead, you’d adopt PNG or lossless WebP, which is very different from regular WebP—did I mention that the process was complicated?
AVIF supports transparency, accommodating both sharp-edged and continuous-tone imagery. No matter what the input looks like, AVIF significantly outperforms WebP, JPEG, and PNG.
Also! Unlike WebP, JPEG, and PNG, AVIF works well with 10-bit bit depths, which is a necessity for HDR and wide-gamut imagery.
The one thing AVIF does not excel at is lossless compression. But you don’t really need that for the web.
As other new image formats emerge, their strengths, weaknesses, and feature sets might recomplicate things. But for now, AVIF is the only next-gen format that enjoys support from a shipping browser, and it consistently beats the web’s other image formats by a wide margin.
Desktop Chrome shipped AVIF support last Fall, and Firefox will ship AVIF support next week. Mobile Chrome will be on board in early March and, when that happens, most web traffic will come from browsers that work with AVIF.
Safari remains mum, but given that HEIC’s patent story is web hostile and that Apple is a founding member of the Alliance for Open Media, the odds look good.
While you wait—for years—for universal support for AVIF and for nonsupporting browser versions to vanish from the scene, the only responsible way to serve AVIFs on the web is with fallbacks:
<source type="image/avif" srcset="dog.avif" />
<source type="image/webp" srcset="dog.webp" />
<img src="dog.jpg" alt="A dog chasing a ball." />
To actually generate the little guys, you have a couple of options:
First, you can encode AVIFs with the amazing Sqoosh app, manually tuning them for a tradeoff between optimal quality and file size.
Or, on Cloudinary, add
f_avif,q_auto to the URLs and let the platform figure out the details. For example:
You might notice that encoding AVIFs with Squoosh is slow.
In fact, with certain encoding settings, the open-source libraries in Squoosh can spend a whopping 50x the effort encoding an AVIF versus a JPEG. Spending 10 full seconds encoding a single image goes against Cloudinary’s on-the-fly transformation experience. Hence, instead of an off-the-shelf, royalty-free codec, Cloudinary leverages the best proprietary codec available. We recently switched over to Visionular’s best-of-breed encoder, which is significantly more efficient.
Last, we’re working on integrating AVIF into
f_auto. If all goes as planned, we’ll release beta support for serving AVIFs in response to
f_auto requests soon.
If your URLs contain
f_auto,q_auto transformations, you’ll be able to reap the huge benefits of AVIF soon with no implementation effort at all.
If you just can’t wait to start delivering images that are half the size of JPEGs, opt for AVIF by adding
f_avif,q_auto to your URLs and delivering them—along with the appropriate fallbacks—using the
In short, AVIF is here and it’s great. The easiest way to adopt it is with Cloudinary. Go right ahead.