Skip to content

AVIF format explained — when 30% smaller than WebP is worth the fallback

Tool author & maintainerPublished Apr 26, 202612 min read

AVIF (AV1 Image File Format) wraps a single AV1 video keyframe in a HEIF container, reaching ~20–30% smaller files than WebP at the same visual quality. The catch is a long tail of compatibility holes — Outlook desktop, the Edge mail client, older Android Webview, and the macOS Mail preview all still fail. AVIF earns its place behind a `<picture>` element with WebP fallback, not as a sole format.

What is AVIF, technically?

AVIF stores a single AV1 video keyframe (intra-coded I-frame) inside a HEIF container, the same container as iPhone HEIC. The AV1 codec is the open-source heir to VP9 and HEVC, designed by the Alliance for Open Media specifically to be royalty-free. Because AV1 is video-grade, it has a much richer toolkit (variable block sizes, sophisticated transforms, advanced entropy coding) than JPG's 1992-era DCT or even WebP's VP8-derived intra mode — that toolkit is what produces the 20–30% extra savings.

Browser support — where does AVIF actually fail?

Native AVIF decoding shipped in Chrome 85 (2020), Firefox 93 (2021), Safari 16.4 (2023), Edge 121 (2024). That covers ~92% of global traffic in 2026. The remaining 8% are: Outlook desktop email rendering (uses Word, no AVIF decoder), Microsoft Edge mail preview (same), older Android Webview embeddings inside apps that haven't updated their bundled Webview, the macOS Mail.app inline preview on macOS 13 and older, and a long tail of niche browsers and IoT viewers.

The `<picture>` fallback pattern

Production-safe AVIF lives behind `<picture>` with explicit fallback: `<source srcset="hero.avif" type="image/avif">` first, `<source srcset="hero.webp" type="image/webp">` second, `<img src="hero.jpg" alt="...">` last. Browsers evaluate the sources top-down and use the first one they can decode. The `<img>` is also the layout fallback if all sources fail — which means modern browsers see AVIF, older browsers see WebP, and the absolute worst case sees JPG. No JS required.

When is AVIF worth it?

Three sweet spots. (1) High-traffic content sites where every kilobyte saved on the hero image moves LCP. (2) Image-heavy product galleries on e-commerce where the cumulative bandwidth saving across thousands of products is meaningful. (3) Photography portfolios where the per-image quality at small file sizes matters for the visual experience. Three places where AVIF is overkill: low-traffic blogs (the encoding cost dwarfs the bandwidth win), email templates (Outlook can't see it), short-lived social media uploads (the platform re-encodes anyway).

Encoding cost and the build-time vs runtime split

AVIF encoding at quality 60 takes roughly 10× the wall-clock time of JPG quality 82 for the same input. Encoding 100 product images can take 2–3 minutes on a workstation; on an edge function with a 10 s budget, it would time out. Encode at build time or in a background job, never on the user-upload critical path. Decoding, by contrast, is fast — most browsers decode an AVIF in under 50 ms regardless of original encoding effort.

Steps

About 2 min
  1. Pick the master file

    Use the original PNG/RAW/TIFF when possible. JPG-only is fine; AVIF tolerates moderate JPEG input better than WebP does.

  2. Open the AVIF converter

    Drop the file into the in-browser tool. Default quality 60 hits the WebP-beating sweet spot for photos.

  3. Run the encode

    Encoding takes 5–15 seconds per image — slower than WebP, faster than running cwebp + cavif locally because no CLI install.

  4. Wire up the `<picture>` fallback

    On your site, serve AVIF first, WebP second, JPG as the `<img>` source. Browsers pick the first they can decode.

Same 1920×1280 hero photo, three modern formats — visually equivalent
FormatFile sizeEncoding time (M2)Browser support 2026
JPG quality 82245 KB0.1 s100%
WebP quality 82165 KB0.4 s98%
AVIF quality 60115 KB4.2 s92%
Measured on 14" MacBook Pro M2, Chrome 139, libavif-compiled-to-WebAssembly via the in-browser tool, sample 1920×1280 RAW photo (2026-04-26).

Frequently asked questions

  • Does AVIF support transparency?

    Yes — full alpha channel support, including 10-bit alpha for smooth gradient fades. WebP also supports alpha; AVIF's encoded alpha is typically smaller.

  • Is animated AVIF a thing?

    Yes (AVIS — AVIF Image Sequences). Browser support is narrower than for static AVIF; for animation today, animated WebP has wider compatibility.

  • Does AVIF support HDR?

    Yes — 10-bit and 12-bit AVIF can carry HDR10 metadata. Currently displayed correctly only on HDR-capable screens via Safari and Chrome on macOS / iOS.

  • How do I serve different sizes?

    Combine `<picture>` with `srcset` and `sizes` on each `<source>`. Browsers pick the right format AND the right resolution based on viewport.

  • Will AVIF replace JPG?

    Not in the foreseeable future — JPG's universal compatibility (every email, every printer, every legacy app) is irreplaceable. AVIF is a high-end optimisation, not a replacement.

  • Is the encoder slow because of the browser?

    No — AVIF encoding is just expensive. The browser's WebAssembly encoder (libavif compiled) is roughly 10–20% slower than the same library natively, but the dominant cost is the AV1 codec itself.

Try it now

Ultra-light images with the modern AVIF format

AVIF Converter

We measure anonymous usage with cookieless analytics. See our privacy policy.