AVIF Format: Compression, Browser Support & Use Cases

Why was AVIF created?

AVIF (AV1 Image File Format) is the still-image counterpart to the AV1 video codec. AV1 was developed by the Alliance for Open Media (AOMedia) — a consortium including Google, Mozilla, Microsoft, Cisco, Intel, Netflix, Amazon, and Apple — and the first AV1 specification was published in 2018. AVIF, derived from AV1's intra-frame coding, was specified by AOMedia in 2019.

The design priorities:

Best-in-class compression for both lossy and lossless still images.
Royalty-free like AV1 itself, to avoid the patent friction that has historically slowed image-format adoption.
Modern feature parity — 10/12-bit colour depth, HDR, wide colour gamut, alpha transparency, animation.

The bet paid off on compression. AVIF produces meaningfully smaller files than WebP at the same visual quality — typically 20–30% smaller for photographic content. For low-bitrate use (heavily compressed thumbnails, low-bandwidth contexts), the win is larger.

What is inside an AVIF file?

AVIF uses the ISOBMFF (ISO Base Media File Format) container — the same container family as MP4 and HEIC. This was deliberate: ISOBMFF is well-tested, broadly supported in tooling, and naturally accommodates AV1's coded image data.

A typical AVIF file contains:

ftyp box identifying the file type and brand.
meta box containing metadata, item info, and item references.
One or more coded image items (the primary image and optional alternates).
Optional mdat containing the actual image data.

The format supports image sequences (animations) through the same container mechanisms that MP4 uses for video.

How does AV1 still-image coding work?

AV1's still-image mode applies the codec's intra-frame prediction and transform tools to a single image. The headline tools:

Block-based prediction with variable block sizes from 4×4 up to 128×128 pixels. The encoder picks the block size that best captures the local image content.
More prediction modes than WebP — directional intra prediction, paeth prediction, smooth prediction, recursive intra modes.
Transform coding using DCT, ADST, identity transforms, and walsh-hadamard transforms, selected per block.
Loop filtering — constrained directional enhancement filter (CDEF) and loop restoration filter, both more sophisticated than WebP's deblocking filter.
Entropy coding via arithmetic coding (more efficient than WebP's entropy coding).

The combined effect is roughly 20–30% smaller files than WebP at equivalent quality on photographic content. The relative advantage is larger at low bitrates and smaller at high bitrates.

What compression modes does AVIF support?

AVIF supports:

Lossy — the most common use case. Quality factor 0–100 (encoder-dependent interpretation). Sweet spot for web delivery: 60–75.
Lossless — exact reconstruction. Roughly competitive with lossless WebP and PNG; sometimes wins, sometimes loses, depending on content.
HDR / wide colour gamut — 10-bit and 12-bit per channel encoding for HDR content. Supports BT.2020, Display P3, and other modern colour spaces.
Animation — image sequences with full per-frame compression.

The lossy mode is where AVIF's compression advantage is most pronounced. For typical web photography, AVIF at q=60 produces files comparable in quality to WebP at q=75, with meaningfully smaller bytes.

Which browsers support AVIF?

Browser adoption was rapid:

Chrome / Edge — supported since version 85 (August 2020).
Firefox — supported since version 93 (October 2021).
Safari — supported since 16 (September 2022 / iOS 16). Earlier versions on macOS Big Sur+ via OS-level decoder.
Mobile browsers — Chrome Android, Samsung Internet, Safari iOS 16+.

Global support sits in the 94–95% range as of 2026. The gap behind WebP (97%+) is narrow and continues to close.

For broader compatibility detail, see WebP Browser Support — the same fallback patterns apply.

What are AVIF's encoding trade-offs?

AVIF's compression win comes at a cost: encoding is dramatically slower than WebP encoding. A single 1200×800 image that takes 200ms to encode as WebP at high effort can take 5–20 seconds as AVIF at high effort.

Implications for build pipelines:

For static site generators encoding hundreds or thousands of images at build time, AVIF can balloon build times.
For on-the-fly encoding (CDN-level conversion), the latency cost matters for cache misses.
For one-time encoding of important assets (heroes, key product photos), the time investment is justified.

Decoding is also slower than WebP, particularly on low-end mobile devices. The byte savings on transfer can be partially offset by longer decode times. Always measure on real target devices.

Modern AVIF encoders worth knowing:

avifenc — the reference encoder from libavif. Standard for command-line work.
rav1e — Rust-based AV1 encoder. Faster than the reference encoder at the cost of slightly larger files.
Sharp (Node.js) — production-grade pipeline support since v0.31.
Squoosh — interactive browser-based encoder. Good for tuning.

# Standard AVIF encoding with default speed (slow, high quality)
avifenc --speed 4 --min 30 --max 50 input.jpg output.avif

# Faster encoding for build pipelines
avifenc --speed 8 --min 30 --max 50 input.jpg output.avif

The --speed parameter accepts 0–10. Lower is slower and produces smaller files; higher is faster and produces larger files. --speed 4 is a reasonable balance for build-time encoding; --speed 6–8 for on-the-fly conversion.

How does AVIF compare to WebP?

The practical comparison:

Dimension	AVIF	WebP
File size (photographic)	Best — 20–30% smaller than WebP	Strong — 25–35% smaller than JPEG
Encoding speed	Slow	Fast
Decoding speed	Slower (on low-end devices)	Fast
Browser support	~94–95%	~97%
Tooling maturity	Improving rapidly	Mature
HDR / 10-bit / 12-bit	Native support	Limited
Lossless mode	Competitive with PNG / WebP	Strong
Animation	Supported	Supported

For sites already shipping WebP, the marginal byte savings from also shipping AVIF are typically 5–15% off the WebP baseline. Whether that's worth the encoding cost and the additional <source> element is a per-site decision.

Is AVIF still relevant today?

AVIF is the format to ship for:

New sites where you control the delivery pipeline and care about absolute minimum bytes.
Image-heavy sites where the cumulative byte savings justify the encoding cost.
HDR or wide-colour-gamut content where AVIF's bit depth matters.
Sites already on a modern image CDN that handles encoding automatically.

AVIF is harder to justify for:

Sites with build-time pipelines where encoding time is a constraint.
Sites with low-end mobile audiences where decode time may offset transfer savings.
Sites where WebP is already shipping and the additional complexity isn't worth the marginal saving.

How do you implement AVIF?

AVIF with WebP and JPEG fallbacks via <picture>:

<picture>
  <source
    type="image/avif"
    srcset="
      /img/photo-800.avif 800w,
      /img/photo-1200.avif 1200w,
      /img/photo-1800.avif 1800w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <source
    type="image/webp"
    srcset="
      /img/photo-800.webp 800w,
      /img/photo-1200.webp 1200w,
      /img/photo-1800.webp 1800w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <img
    src="/img/photo-1200.jpg"
    srcset="/img/photo-800.jpg 800w, /img/photo-1200.jpg 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
    alt="..."
    width="1200"
    height="675"
    loading="lazy"
    decoding="async"
  />
</picture>

The browser picks the first format it supports. AVIF-capable browsers get AVIF; WebP-capable browsers get WebP; everyone else gets JPEG. Detailed pattern guidance in WebP Browser Support.

For framework-specific integration:

Next.js — next/image supports AVIF when formats: ["image/avif", "image/webp"] is set in next.config.js. See WebP in React.
Cloudflare Images, Cloudinary, Imgix, Vercel — most modern image CDNs support automatic AVIF serving with Accept-header negotiation.

When is AVIF the wrong choice?

Despite the compression win, AVIF is not always the right answer:

Very small images (favicons, small icons) — the AVIF container overhead approaches the payload. WebP or PNG often wins.
Tiny thumbnails at low pixel counts — JPEG with aggressive compression can be smaller because the codec overhead dominates.
Pure-vector content — SVG always wins for content that's natively vector.
Content that needs editing round-trips — encoding round-trips compound losses. Keep the source as a lossless format and re-encode as needed.