What Is AVIF Format? Next-Gen Image Compression Explained
What Is AVIF Format? Next-Gen Image Compression Explained
AVIF format is the smallest mainstream image format you can ship today. At matched visual quality it lands roughly 40-60% below JPEG and 20-50% below WebP, which on an image-heavy page is the difference between a fast site and a slow one.
For years the honest answer to "should I use AVIF" was "not yet, browser support is not there." That answer expired. Support now sits around 93-94% globally, and the remaining gap is handled by a fallback you should be writing anyway.
The real tradeoff moved somewhere else, and it is worth understanding before you convert a library.
Where AVIF Comes From
AVIF stands for AV1 Image File Format. It is not a new compression technique invented for photos — it is the AV1 video codec's intra-frame compression, the part that encodes a single keyframe without reference to any other frame, applied to still images and wrapped in a HEIF container.
That lineage explains most of its behaviour. AV1 was designed by the Alliance for Open Media — Google, Netflix, Amazon, Mozilla, Apple and others — specifically to beat HEVC without the patent licensing. AVIF inherits that: it is royalty-free, which is precisely why it spread and why HEIC, technically comparable, did not escape Apple's ecosystem. If you want the video side of that story, see what is the AV1 codec.
The specification was published in February 2019. Chrome shipped support in 2020, Firefox in 2021, Safari in 2022 with version 16.
What AVIF Actually Supports
AVIF is unusually complete for an image format. In one file it handles:
- Lossy and lossless compression
- Alpha transparency, a full channel rather than the 1-bit on/off of GIF
- Wide colour gamut and HDR, up to 12-bit colour depth
- Animation, so it can stand in for animated GIF
- Chroma subsampling at 4:2:0, 4:2:2 or 4:4:4
- Film grain synthesis, where grain is stripped before encoding and re-synthesised on decode
That last one is genuinely clever and explains why AVIF does so well on photographic content. Film grain and sensor noise are extremely expensive to encode faithfully — they are close to random, which is the worst case for any compressor. AVIF can discard the grain, store a compact description of its character, and regenerate something statistically similar at display time. The image looks right, and you never paid to store the noise.
The 12-bit depth matters more than it sounds. 8-bit images band visibly in smooth gradients — skies, studio backdrops, subtle shadows. AVIF encoding at higher bit depth largely removes that banding even when the source was 8-bit.
The Size Difference in Practice
Published figures cluster around 40-60% smaller than JPEG and 20-50% smaller than WebP at equivalent visual quality. The spread is wide because content type drives the result far more than the format comparison suggests:
AVIF wins biggest on: photographs, images with smooth gradients, anything with film grain or noise, and images with large flat regions of colour.
AVIF wins least on: small images, where container overhead is proportionally significant; images already heavily compressed, where the information is gone; and sharp-edged graphics such as screenshots of text, where PNG's lossless approach is competitive and sometimes better.
The practical takeaway: run your own numbers on your own images. A photography portfolio and a documentation site full of UI screenshots will get very different results, and only one of them will match the headline figures.
For a direct comparison against the format most sites are on now, see AVIF vs WebP.
The Catch: Encoding Speed
This is the tradeoff that replaced browser support, and it gets glossed over constantly.
AVIF encoding is roughly 2-10x slower than WebP, and dramatically slower than JPEG. That range is wide because AVIF encoders expose a speed/quality dial — push for maximum compression and encoding time climbs steeply for diminishing returns.
Whether this matters depends entirely on when you encode:
Build-time or one-off encoding — not a problem. If you are converting a media library, or generating images during a site build, slow encoding costs you some minutes once. Take the compression win.
Real-time encoding of user uploads — a real problem. If users upload images and you convert on the fly, AVIF encoding time becomes request latency and CPU cost. At any volume, WebP remains the pragmatic choice for that path.
A common and sensible pattern: serve WebP immediately on upload, then re-encode to AVIF in a background job and swap it in.
How to Actually Ship It
Never serve AVIF alone. Use the <picture> element so the browser picks the best format it understands:
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="Description" width="1200" height="800">
</picture>
The browser walks the sources in order and takes the first it can decode. AVIF-capable browsers get the smallest file; Safari 15 gets WebP; anything older gets the JPEG. No JavaScript, no user agent sniffing, no server configuration.
Three details worth getting right:
Always include width and height on the img. It reserves layout space and prevents the content shift that hurts Cumulative Layout Shift scores.
The img must stay last. It is both the final fallback and the element that actually carries alt, sizing and loading attributes.
Check your CDN and build pipeline serve image/avif with the correct MIME type. A misconfigured content type is the most common reason a correctly-authored picture element silently falls through to JPEG.
If you are choosing formats across a whole site rather than just evaluating AVIF, best image format for websites covers the full decision.
Quality Settings That Hold Up
AVIF quality scales do not map onto JPEG's. A JPEG at quality 80 and an AVIF at quality 80 are not comparable, and assuming they are is how people conclude AVIF "looks worse."
Useful starting points:
- Photographic content for the web: quality 50-65 in most AVIF encoders looks equivalent to JPEG at 80-85, at a fraction of the size
- Images needing to survive cropping or zoom: 70-80
- Graphics with hard edges and text: consider lossless AVIF, or stay on PNG and compare
The reliable method is to encode one representative image at several settings and look at them at display size on a decent screen. Doing this once per content type gives you a setting you can apply in bulk with confidence. If the underlying concepts are unfamiliar, lossy vs lossless compression is the background.
Should You Convert an Existing Library?
Two situations, different answers.
You still have the originals. Convert from those. Encoding AVIF from a master file captures the full benefit.
You only have compressed JPEGs. You are re-encoding lossy on top of lossy. The JPEG already discarded information, and AVIF cannot recover it — it faithfully encodes the artefacts too. You will still usually save meaningful size, but sample a dozen representative files at your chosen quality and look at them before running a batch across thousands.
Either way, keep the originals. Format preferences change; this is the third "next-gen image format" in fifteen years, and the sites that kept masters are the ones that re-encoded cheaply each time.
Converting Images on a Mac
Doing this by hand — running encoder binaries, tuning quality per image type, converting a folder at a time — is exactly the work that gets abandoned halfway through.
Compresto handles image conversion and compression in batch on macOS. Drop in a folder, pick a quality level or a target size, and it processes everything at once, converting between JPEG, PNG, WebP, HEIC and other formats as needed.
It runs entirely locally, so nothing is uploaded to a third-party conversion service — worth caring about for client work or anything not yet published — and it handles video and PDFs the same way.
Related: convert images to WebP on Mac and optimize images for web.
Frequently Asked Questions
What is AVIF format?
AVIF stands for AV1 Image File Format. It applies the AV1 video codec's intra-frame compression to still images, in a HEIF container. Published by the Alliance for Open Media in February 2019 and royalty-free, it produces files roughly 40-60% smaller than JPEG and 20-50% smaller than WebP at matched quality.
Is AVIF better than WebP?
On file size, yes — typically 20-50% smaller at equivalent quality, with the biggest lead on photographs and gradients. On encoding speed, no: AVIF is roughly 2-10x slower. Serve AVIF first with WebP as fallback and you get both.
Do all browsers support AVIF in 2026?
Support is around 93-94% globally, covering current Chrome, Edge, Firefox, Safari 16+, and Samsung Internet. The gap is older Safari and legacy browsers, which a picture element fallback handles.
Does AVIF support transparency and animation?
Both. It has a full alpha channel, so it replaces transparent PNG at much smaller sizes, and it supports animation as a GIF replacement. Animated AVIF tooling is thinner than animated WebP, so test before committing.
Is AVIF lossy or lossless?
Both. Lossy is what nearly everyone uses on the web. Lossless AVIF still beats lossless PNG on most images, though by a narrower margin than in the lossy case.
Why is my AVIF file larger than the JPEG?
Usually one of three things: the image is small enough that container overhead dominates, the source was already heavily compressed so there is little redundancy left, or the quality setting is far higher than intended because AVIF's scale does not match JPEG's. Try a lower quality value first.
Should I convert my existing JPEGs to AVIF?
Convert from originals where you have them. Converting an already-compressed JPEG is lossy-on-lossy and recovers only part of the benefit — usually still a size win, but sample a few files at your target quality before running it in bulk.