What is AVIF — and should you use it in 2026?

AVIF (AV1 Image File Format) is an image format whose compression comes from the AV1 video codec — the royalty-free codec developed by the Alliance for Open Media (Google, Mozilla, Apple, Microsoft, Amazon, Netflix, and others). Instead of inventing a new way to compress still images, its designers took the intra-frame coding tools that AV1 already uses to compress video keyframes and wrapped them in a still-image container. Because AV1 inherited a decade of research into how human vision discards detail, AVIF starts from better math than the 1990s-era algorithms behind JPEG and PNG, and the result is typically 30–50% smaller than JPEG at the same visual quality, with support for features those formats handle poorly: alpha transparency, animation, HDR, and high bit depth.

Three mechanisms account for most of the savings. First, more flexible block partitioning: AV1 splits an image into blocks that adapt to content — a flat sky region becomes one large block, a detailed face edge becomes small ones — where JPEG is locked into an 8×8 grid regardless of content. Second, better prediction: AVIF can predict pixel regions from neighbors in multiple directions and multiple reference frames (for animation), coding only the residual error. Third, an in-loop restoration filter designed against perceptual models, which cleans up artifacts the encoder knows your visual system would not forgive.

The practical consequence is that AVIF wins hardest exactly where JPEG struggles: photographs with fine texture, gradients that band in JPEG, and mixed content like a screenshot containing both text and photo. A typical modern photograph lands around 40–60% of its JPEG size at equivalent quality; graphics with transparency, where JPEG was never usable and PNG was the fallback, often come in at a third of the PNG size while keeping smooth alpha edges.

AVIF has been supported in every major browser for years — Chrome, Edge, Firefox, and Safari (desktop and iOS) all decode it natively, which covers the overwhelming majority of real visitors. The residual audience on ancient browsers is small enough that a proper fallback (the <picture> element or CDN content negotiation) handles it invisibly, and services that serve modern formats with fallbacks report AVIF adoption above 90% of requests on typical traffic.

The support gaps that still matter are not browsers but workflows: some desktop image editors open AVIF slowly or not at all, older photo printers and some publishing systems reject it, and Windows without a recent codec pack may not preview thumbnails. The rule that keeps this simple: AVIF is a delivery format, not a master format. Keep your masters as PNG, JPEG, or TIFF; generate AVIF when exporting for the web, exactly as you would generate WEBP today.

Use AVIF for: hero and banner photographs (the largest bytes on a page, where 40% savings compounds across every visit); galleries and product photos (multiplicative savings); any image needing transparency that is photographic rather than flat-colored; animations that would otherwise ship as GIF (AVIF animation crushes GIF’s 256-color ceiling and its per-frame waste); and any image a user uploads where you control the pipeline.

Do not reach for AVIF when: the image is a screenshot or UI graphic with sharp text and few colors — PNG (or lossless WEBP) keeps text crisper at smaller sizes for that content class; the destination is print or a legacy publishing workflow; your audience statistics show meaningful numbers of ancient clients; or your encoding pipeline cannot wait — AVIF encoding is computationally heavy, several times slower than JPEG, which matters when you convert thousands of images interactively. In a browser-based converter that cost is your own machine waiting a few extra seconds; in a server pipeline converting millions of images it is a real budget item.

• Heroes, photos, galleries: AVIF, quality ~50–70
• Transparent photographs: AVIF (or WEBP if support must be universal-old)
• Screenshots, logos, flat graphics: PNG or lossless WEBP
• Masters: always keep PNG/JPEG/TIFF — AVIF is for delivery

In the image studio, AVIF is a first-class output: drop any supported input — PNG, JPG, WEBP, HEIC, GIF, BMP, TIFF — pick AVIF as the target, and the conversion runs in browser memory. For photos, start around quality 60 and inspect at 100% zoom; AVIF’s quality slider is not calibrated to JPEG’s numbers, and 60 in AVIF typically matches or beats 85 JPEG visually while being far smaller. Push toward 75–80 only for images with text or fine engraved detail; drop to 45–50 for background and decorative images where nobody will zoom.

Two conversion habits worth building in. First, convert from the highest-quality original every time — AVIF-of-an-AVIF inherits the first pass’s losses for no benefit, the same re-encode trap every lossy format shares. Second, check the edge cases the encoder is least consistent about: smooth gradients (look for banding in skies), thin white-on-dark text (the highest-risk detail class in any lossy codec), and skin texture in portraits. If those three look right at 100%, the rest of the image will too.

The two safe serving patterns are the <picture> element and CDN content negotiation. <picture> puts AVIF first with a JPEG or WEBP source as fallback, and the browser picks the first format it can decode — no sniffing, no user-agent lists. CDN negotiation achieves the same thing server-side: the client advertises image/avif in Accept, the edge serves AVIF, and anything else gets the JPEG. Both are one-time plumbing; neither requires choosing between formats per visitor by hand.

For search and social, nothing changes: AVIF images carry the same alt text, structured data, and sitemap entries as any other format, and Google has processed AVIF for years. The one operational note is caching: AVIF and JPEG variants are different files, so make sure your cache keys include the format (they will if you use separate URLs via <picture>; watch out only if you are overwriting a single URL with format-negotiated rewrites). And keep the fallback file small too — the point of AVIF is speed, and shipping a 900 KB JPEG to every legacy visitor still costs them a slow page.

AVIF in 2026 is a default, not a gamble: for photographs and photographic graphics destined for browsers, export AVIF with a fallback and move on. Its remaining limits are practical, not technical — encoding cost, workflow support, and the small tail of old clients — and each is handled by a standard pattern rather than a workaround. What has not changed since JPEG was invented is the discipline around it: start from the best original, choose the quality by looking at the result at 100% zoom, and never re-encode an already-compressed file. The format keeps getting better at the math; the workflow still lives in your habits.