AVIF vs WebP in 2026: Which Format Should Your Website Use?

What AVIF Actually Is

AVIF stands for AV1 Image File Format. It uses intra-frame compression from theAV1 video codec, developed by the Alliance for Open Media, applied to still images. AV1 was designed from scratch in 2018 to outperform VP9 and H.265, and AVIF inherits those compression algorithms for photos. Skip the codec history and the practical point is this: a photo that lands at 150 KB as JPEG often fits in 75 KB as AVIF at the same visual quality.

WebP was released by Google in 2010. It uses VP8 video compression for lossy encoding and a custom lossless variant. It improved on JPEG and PNG in most benchmarks at the time, but it predates the AV1 codec by eight years.

The Compression Numbers

According toNetflix AVIF researchand independent testing by theCtrl.blog image codec study, AVIF saves roughly 50% versus JPEG and about 20% versus WebP at equivalent visual quality (measured by SSIM and DSSIM metrics). Treat those as representative benchmark figures, not a promise for every photo. A busy cityscape and a flat logo compress very differently.

The Feature the Compression Tables Don't Show: HDR and Wide Color

File size comparisons get most of the attention, but AVIF has a technical capability that does not show up in a compression table at all: native support for HDR and wide-gamut color spaces through the same underlying AV1 bitstream used for HDR video. JPEG is fundamentally limited to 8-bit color depth in the sRGB space it was designed around in the early 1990s. AVIF supports up to 12-bit color depth and color spaces like Rec. 2020, documented in the AVIF specification maintained by the Alliance for Open Media. For most web content this is invisible, since most displays and most source images are still 8-bit sRGB. But for photography and design work destined for modern HDR displays, it is a genuine capability gap that WebP, despite its other strengths, does not close.

AVIF and WebP browser support in 2026

AVIF has 93% global browser support as of 2026, per caniuse.com. That number moved from a question mark to a non-issue over about three years. The remaining gap is not your users on Chrome. It is older iOS and locked-down corporate Windows. Full breakdown:

That 7% gap is mostly iOS 15 and older Edge. A WebP fallback inside a <picture> element covers them. The right way to write it:

<!-- Serve AVIF to supported browsers, WebP as fallback, JPEG as last resort --><picture>  <source srcset="/hero.avif" type="image/avif" />  <source srcset="/hero.webp" type="image/webp" />  <img    src="/hero.jpg"    alt="Hero image showing FileMint converter interface"    width="1200"    height="630"    loading="lazy"  /></picture>

Where WebP Still Wins: Encoding Speed

AVIF's compression advantage has a cost: encoder speed. AVIF encoding is significantly slower than WebP at the same quality level.

# Encoding a 2000x1500px photo at quality 80 on an M2 MacBook Pro# (using sharp npm package, based on libvips) WebP encode time:  ~35ms   → output: 110 KBAVIF encode time:  ~450ms  → output: 72 KB # AVIF is 12x slower to encode, but 35% smaller output# For real-time browser-side conversion: WebP is more responsive# For pre-processed build pipeline: AVIF is worth the wait

For a static site build pipeline (Next.js, Astro, Hugo), AVIF encoding runs once at build time — the 450ms per image is invisible to users. But for real-time browser-side image conversion tools like FileMint's compressor, WebP produces faster results with nearly as good compression. Our technical guide to client-side tools explains why keeping that encode on the user's machine matters for both speed and privacy.

Implementing AVIF in Next.js

Next.js automatically serves AVIF through itsImage componentwhen you configure the formats in next.config.js:

// next.config.jsmodule.exports = {  images: {    formats: ['image/avif', 'image/webp'],    // AVIF is tried first; WebP used if browser doesn't support AVIF    // Falls back to the src format (JPEG/PNG) if neither is supported  },}; // In your component — Next.js handles format negotiation automaticallyimport Image from 'next/image'; export default function Hero() {  return (    <Image      src="/hero.jpg"      alt="Chrome DevTools Network tab showing AVIF image payload"      width={1200}      height={630}      priority // LCP image — load eagerly    />  );}

With this configuration, Next.js sends AVIF to Chrome, Safari 16+, and Firefox 93+. It sends WebP to older browsers. Your source image can remain as JPEG or PNG — conversion happens on-demand and is cached automatically.

Edge Cases and Common AVIF Problems

Small Thumbnails: AVIF Can Be Larger Than WebP

AVIF's compression advantage disappears for very small images. At dimensions below ~100×100 pixels, the AVIF container overhead can make the file larger than an equivalent WebP or even JPEG.

# 32x32px icon compression testJPEG: 1.2 KBWebP: 0.8 KB  ← winner for small iconsAVIF: 1.4 KB  ← larger than JPEG at this size! # Rule of thumb: use WebP (or PNG) for icons and thumbnails below 100px

High-Contrast Images and Color Banding

AVIF at low quality settings (below quality 60) can produce visible color banding on gradients and flat-color graphics. WebP handles these cases more gracefully. For UI screenshots, illustrations, and graphics with large flat areas, test AVIF at quality 75+ before committing to it.

Out-of-Memory Errors with Large AVIF Files

The Sharp image processing library (used in Node.js) has a known memory constraint with AVIF encoding of very large images. Encoding a 6000×4000 AVIF on a server with less than 2GB available memory can cause the process to crash.

// Handle sharp AVIF memory errors gracefullyimport sharp from 'sharp'; async function convertToAvif(inputPath: string, outputPath: string) {  try {    await sharp(inputPath)      .resize({ width: 2000, withoutEnlargement: true }) // cap max dimension      .avif({ quality: 75, effort: 4 }) // effort 4 = balanced speed/quality      .toFile(outputPath);  } catch (err) {    // Fall back to WebP if AVIF encoding fails    console.warn('AVIF encoding failed, falling back to WebP:', err.message);    await sharp(inputPath)      .resize({ width: 2000, withoutEnlargement: true })      .webp({ quality: 80 })      .toFile(outputPath.replace('.avif', '.webp'));  }}

iOS 15 AVIF Rendering Bug

Safari on iOS 15 has a known bug where AVIF images with transparency (alpha channel) render with incorrect colors. The fix is to always include a WebP fallback in your<picture> tag — which you should be doing anyway. iOS 16 resolved this.

My Recommendation: AVIF for Production, WebP as Fallback

I encode all new production images as AVIF in the build pipeline. The 50% size reduction over JPEG reduces LCP time directly — which is a Google ranking signal under Core Web Vitals.

Use this decision matrix:

If you are using image optimization as part of a broader site speed effort, read our complete image optimization guide for the full checklist — resizing, lazy loading, and responsive srcset setup. And if you are compressing images locally without uploading them, our web performance case study shows the real PageSpeed score improvements from a production site migration. Want the deeper reasoning on why local conversion beats sending files to a server? Our client-side file processing privacy guide covers it.

Google's WebP documentation and WebP FAQ are the primary source for the compression comparisons above, and web.dev's image guide covers the broader format picture, including where AVIF fits next to WebP. For measured, real-world encode-speed and file-size numbers rather than codec specs, Google's AVIF coding comparison and PicLab's compression benchmarks are worth a read before you commit to a pipeline.