Ship AVIF Without Breaking the Last 6%

AVIF renders natively in ~94% of browsers worldwide in 2026. A three-line <picture> fallback covers the rest automatically. This guide gives you the exact numbers, names the holdouts, and shows the one pattern that makes AVIF safe to ship today.

For the format itself, see AVIF format overview. For where it fits in performance work, see AVIF Optimization.

Is AVIF safe to use in 2026?

Yes — AVIF is production-safe with a fallback. It reaches ~94% of global users per caniuse, and the remaining ~6% are caught by a <picture> element's WebP and JPEG sources at zero extra cost.

The only requirement is that you ship a fallback. AVIF-first delivery with no fallback breaks for iOS 15 users and some embedded browsers; AVIF-first delivery with a fallback breaks for nobody.

The support timeline

Each browser engine shipped AVIF on a different date. Four milestones define the rollout:

Chrome — version 85, August 2020, no flag.
Firefox — version 93, October 2021, on by default.
Safari (iOS 16 and macOS Ventura) — September 2022; animation and grid images followed in Safari 16.4, March 2023.
Edge — version 121, January 2024. Edge is Chromium-based but kept AVIF behind a flag for three years before enabling it by default.

The gap between Chrome (2020) and the last engine, Edge-by-default (2024), is why AVIF lagged WebP on global coverage until recently. That gap has now closed.

Who is in the remaining ~6%?

The non-supporting tail is small, specific, and shrinking. Three groups make up almost all of it:

iOS 15 and earlier — Safari gained AVIF in iOS 16, so devices stuck on iOS 15 or older (mostly pre-2018 iPhones) cannot decode it.
Locked-down corporate Windows — managed fleets pinned to old Chromium or pre-121 Edge builds.
In-app and embedded browsers — some webviews, smart-TV browsers, and game-console browsers on aging firmware.

None of these need special handling. Each falls back to WebP or JPEG through the <picture> element below.

The fallback pattern: `<picture>` with three sources

Use a <picture> element listing AVIF, then WebP, then JPEG. The browser picks the first format it can decode, with no JavaScript:

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

Three ordering rules make this work correctly:

AVIF first — the ~94% with support get the smallest file.
WebP second — at ~96% support, WebP catches iOS 15 and most of the corporate tail.
JPEG on the inner <img> — the universal floor; every browser ever made renders it.

Always set width and height on the <img> to reserve space and avoid layout shift. See Core Web Vitals & Images.

Server-side content negotiation: the single-URL alternative

When you cannot rewrite HTML — legacy CMS, user-generated content, third-party templates — negotiate format on the server instead. The browser's Accept header already declares AVIF support:

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

The server reads that header and returns the best variant from one URL:

# Nginx: serve photo.jpg, but upgrade to .avif or .webp when accepted
map $http_accept $img_ext {
  default     "";
  "~image/avif" ".avif";
  "~image/webp" ".webp";
}

location ~* \.(jpe?g|png)$ {
  add_header Vary Accept;
  try_files $uri$img_ext $uri =404;
}

<img src="/photo.jpg"> then returns AVIF to capable clients, WebP to the rest, JPEG as the floor. Two caveats matter:

Vary: Accept is mandatory — without it, a CDN may cache an AVIF response and serve it to a browser that cannot decode it.
AVIF is checked before WebP in the map, because the header lists both and you want the smaller format to win.

Most managed image CDNs — Cloudflare Images, Cloudinary, Imgix, and Vercel's next/image — do this negotiation automatically.

Feature detection: when `<picture>` is not an option

For CSS backgrounds, <canvas> sources, or anything outside an <img>, you need explicit detection. There is no @supports query for image formats — @supports tests CSS features, not codecs, so it cannot detect AVIF.

Two correct approaches replace it:

CSS: `image-set()` with `type()`

For background images, let CSS negotiate the codec the same way <picture> does:

.hero {
  background-image: image-set(
    url("/img/hero.avif") type("image/avif"),
    url("/img/hero.webp") type("image/webp"),
    url("/img/hero.jpg") type("image/jpeg")
  );
}

image-set() with type() is supported in Chrome, Firefox, and Safari 16+. The browser skips formats it cannot decode. This is the cleanest CSS-native fallback.

JavaScript: decode a 1×1 AVIF probe

When you must branch in JS, attempt to decode a tiny AVIF data URI:

async function supportsAvif() {
  if (!self.createImageBitmap) return false;
  const probe =
    "data:image/avif;base64,AAAAIGZ0eXBhdmlmAAAAAGF2aWZtaWYxbWlhZk1BMUIAAADybWV0YQAAAAAAAAAoaGRscgAAAAAAAAAAcGljdAAAAAAAAAAAAAAAAGxpYmF2aWYAAAAADnBpdG0AAAAAAAEAAAAeaWxvYwAAAABEAAABAAEAAAABAAABGgAAAB0AAAAoaWluZgAAAAAAAQAAABppbmZlAgAAAAABAABhdjAxQ29sb3IAAAAAamlwcnAAAABLaXBjbwAAABRpc3BlAAAAAAAAAAEAAAABAAAAEHBpeGkAAAAAAwgICAAAAAxhdjFDgQAMAAAAABNjb2xybmNseAACAAIABoAAAAAXaXBtYQAAAAAAAAABAAEEAQKDBAAAACVtZGF0EgAKCBgABogQEDQgMgkQAAAAB8dSLfI=";
  const blob = await fetch(probe).then((r) => r.blob());
  return createImageBitmap(blob).then(
    () => true,
    () => false,
  );
}

The probe decodes only on AVIF-capable browsers. Detection is asynchronous, so set a class on <html> and let CSS react, rather than blocking render.

Why you almost never need a polyfill

A true AVIF polyfill is impractical, and the <picture> fallback makes one unnecessary. Two reasons:

Decoding AV1 in JavaScript or WebAssembly is heavy. A WASM AVIF decoder ships hundreds of kilobytes and decodes slowly — it would cost more than the bytes AVIF saves on the exact old devices that lack native support.
The fallback is already lossless coverage. Any browser without AVIF gets WebP or JPEG of the same image. There is nothing left for a polyfill to fix.

Reserve WASM decoding for niche cases — for example, an in-browser AVIF viewer that must run on Safari 15 — not for general image delivery.

FAQ

Does Safari support AVIF? Yes. Safari supports AVIF since version 16 on iOS 16 and macOS Ventura, both September 2022. Animation arrived in Safari 16.4 (March 2023).

What percentage of browsers support AVIF in 2026? About 94% of global browser traffic, per caniuse. WebP sits a few points higher at ~96%.

Do I still need a JPEG fallback if I ship WebP too? Keep JPEG on the inner <img> as the universal floor. It costs nothing extra and covers any client that lacks both AVIF and WebP.

Can I detect AVIF with a CSS @supports query? No. @supports tests CSS features, not image codecs. Use image-set() with type(), a <picture> element, or a JavaScript decode probe instead.

Will using AVIF hurt my SEO? No. Google indexes AVIF in Google Images and ranks it normally. A correct <picture> fallback also guarantees an image always renders.

Where to go from here

AVIF format overview — what the format is and when to use it
AVIF Optimization — the broader performance guide
AVIF Compression Settings — encoder parameter reference
AVIF in React — next/image and component patterns
AVIF on WordPress — native upload since 6.5
Core Web Vitals & Images — layout shift and LCP
Pick your fallback format: WebP, JPG, PNG
Convert your library: JPG to AVIF, PNG to AVIF, AVIF to JPG, AVIF to PNG

Ship AVIF Without Breaking the Last 6%

Is AVIF safe to use in 2026?

The support timeline

Who is in the remaining ~6%?

The fallback pattern: <picture> with three sources

Server-side content negotiation: the single-URL alternative

Feature detection: when <picture> is not an option

CSS: image-set() with type()