← All articles

WebP vs AVIF: Which Next-Gen Image Format Wins in 2026?

WebP and AVIF are both "next-gen" image formats that outperform JPEG and PNG. They compete for the same job: deliver smaller image files without sacrificing visual quality. The practical question is whether AVIF's superior compression is worth its encoding overhead — and for most projects, the answer is nuanced.

Here is how the two formats stack up on every dimension that matters, with real benchmark data and a concrete recommendation you can act on today.

WebP: The Established Standard

Google developed WebP and released it in 2010 with one goal: replace JPEG and PNG on the web. It has largely done that. WebP is now the default image format for Chrome, Android, and Google's own infrastructure.

Compression, Features, and Tooling

WebP supports both lossy and lossless compression within a single format — something JPEG cannot do. Lossy WebP uses predictive coding derived from the VP8 video codec, which applies block transforms and quantization to produce files 25–50% smaller than equivalent JPEGs at comparable quality. Lossless WebP uses a separate algorithm with spatial prediction, color transformations, and Huffman coding to beat PNG by 25–35%.

Beyond compression, WebP handles every format job you encounter on the web:

The tooling ecosystem is mature. libwebp (Apache 2.0 license) has been at version 1.x since 2018 and is embedded in every major browser, image processing library, and CDN. Sharp (MIT license, v0.33.x), ImageMagick (Apache 2.0, v7.1.x), and Squoosh can all encode WebP. Every CDN — Cloudflare, Fastly, Akamai — supports on-the-fly WebP delivery.

AVIF: The Challenger

AVIF (AV1 Image File Format) is the still-image container for frames encoded with the AV1 video codec. AV1 was developed by the Alliance for Open Media — a consortium including Google, Apple, Microsoft, Netflix, and Amazon — and released in 2018. AVIF 1.0 was standardized in 2019.

AV1 Encoding, Superior Compression, and HDR

AV1 achieves better compression than VP8 (WebP's codec) because it is a newer, more computationally expensive algorithm. AV1 uses larger coding units (up to 128×128 blocks vs VP8's 16×16), more prediction modes, loop filters, and a more sophisticated entropy coder. The result: AVIF produces files roughly 20–50% smaller than WebP at equivalent perceptual quality, depending on the source image.

AVIF also supports capabilities that WebP lacks:

The reference encoder is libaom (BSD 2-Clause license), the AOM AV1 encoder. libavif (BSD 2-Clause license) wraps it for still images.

WebP vs AVIF: Feature Comparison

Feature WebP AVIF
Lossy compression Yes (VP8-based) Yes (AV1-based)
Lossless compression Yes Yes
Transparency (alpha) Full 8-bit alpha Full alpha, lossless or lossy
Animation Yes (8-bit color) Yes (via AVIF sequences)
HDR / wide color gamut No (8-bit only) Yes (10-bit, 12-bit, Rec.2020)
Film grain synthesis No Yes
Progressive decode No Limited (via sequences)
Color depth 8-bit Up to 12-bit
Max image dimensions 16,383 × 16,383 65,535 × 65,535
Encoding speed Fast (milliseconds) Slow (seconds to minutes)
Decoding speed Fast Moderate (improving)
Browser support (2026) ~97% global ~93% global
Tooling maturity Excellent Good (catching up)
File size vs WebP Baseline 20–50% smaller
Specification Google (2010) AOM standard (2019)

The compression advantage is real and significant. The encoding speed penalty is equally real and significant. Both matter depending on your workflow.

File Size Benchmark

Same source images compressed to equivalent perceptual quality in both formats, using cwebp v1.4.0 and avifenc (libaom v3.9.0) at comparable quality settings (WebP q80 ≈ AVIF crf24 for photographic content):

Image Type Dimensions WebP (q80) AVIF (crf24) AVIF Savings
Photograph (landscape) 1920×1080 290 KB 185 KB 36%
Portrait (skin tones, detail) 1200×1600 340 KB 198 KB 42%
Screenshot (UI with text) 1440×900 145 KB 110 KB 24%
Illustration (flat color) 800×600 34 KB 28 KB 18%
Product image (white background) 1000×1000 78 KB 52 KB 33%

Photographs and portraits — images with smooth gradients and complex textures — see the largest savings. Flat illustrations and screenshots benefit less because their low entropy compresses efficiently even with simpler algorithms.

A 36% reduction on a 290 KB image saves 105 KB per image. On a product page with 20 images, that is 2.1 MB per page load — meaningful for LCP scores and bandwidth costs at scale.

Browser Support in 2026

AVIF support has matured significantly since 2020. Here is where things stand:

Browser WebP Support AVIF Support AVIF Version Added
Chrome (desktop + mobile) Since v32 (2014) Since v85 (2020) 85
Firefox Since v65 (2019) Since v93 (2021) 93
Safari (macOS + iOS) Since v14 (2020) Since v16.0 (2022) 16.0
Edge Since v18 (2018) Since v121 (2024) 121
Samsung Internet Since v4 (2016) Since v20 (2023) 20
Opera Since v11.1 (2011) Since v71 (2020) 71

As of March 2026, WebP has approximately 97% global browser coverage; AVIF has approximately 93%. The 4-point gap is mostly legacy Android devices (Samsung Internet < v20) and older Safari installations (iOS 15 and earlier still in limited circulation).

For most sites, 93% coverage is sufficient — especially when paired with a proper <picture> fallback (covered below). The sites where AVIF is risky: those with analytics showing meaningful traffic from older iOS, legacy Android, or specific enterprise environments locked to older Edge builds.

Encoding Speed Comparison

This is the most overlooked factor in WebP vs AVIF comparisons, and the one most likely to affect your decision.

AVIF encoding is slow. Not slightly slower — dramatically slower. The AV1 codec was designed for video encoding on powerful hardware over acceptable timeframes. Applying it to still images at high quality produces excellent results, but the compute cost is high.

Measured on a 4-core 3.0 GHz Linux server (AVX2, no GPU acceleration), encoding a single 1920×1080 JPEG source to equivalent quality:

Format Command Encoding Time Output Size
WebP (q80) cwebp -q 80 input.jpg -o output.webp ~90ms 290 KB
AVIF (speed 6, default) avifenc --speed 6 -q 60 input.jpg output.avif ~4.2s 215 KB
AVIF (speed 0, best) avifenc --speed 0 -q 60 input.jpg output.avif ~48s 185 KB
AVIF (speed 8, fast) avifenc --speed 8 -q 60 input.jpg output.avif ~1.1s 248 KB

At default speed settings, AVIF takes roughly 47x longer to encode than WebP for the same image. At best-quality settings (--speed 0), it is over 500x slower.

The practical consequence: batch-encoding a library of 10,000 product images at WebP takes roughly 15 minutes. The same batch at AVIF default speed takes over 11 hours. At AVIF best quality, it approaches 6 days.

This is not a blocker for pre-built static sites where images are encoded once at build time. It is a serious constraint for:

For these use cases, WebP is the only practical choice today. AVIF decoder speed (reading the file in the browser) is much better — modern browsers decode AVIF efficiently. The bottleneck is always on the encoder side.

When to Use WebP

WebP is the right default for the majority of web projects.

Use WebP when:

For a deeper look at the PNG side of the format decision tree, see our PNG vs WebP comparison.

When to Use AVIF

AVIF earns its place in specific, high-value scenarios.

Use AVIF when:

The Practical Recommendation

Do not choose one format and call it done. The optimal setup uses both, with fallback:

<picture>
  <!-- AVIF: best compression for browsers that support it -->
  <source srcset="hero-image.avif" type="image/avif">
  <!-- WebP: fallback for browsers without AVIF support -->
  <source srcset="hero-image.webp" type="image/webp">
  <!-- JPEG/PNG: final fallback for legacy browsers -->
  <img src="hero-image.jpg" alt="Your descriptive alt text here" width="1920" height="1080">
</picture>

The <picture> element lets browsers pick the best format they support. Chrome and Firefox pick AVIF. Older Safari picks WebP. The rare legacy browser falls back to JPEG. You get maximum compression where supported and full compatibility everywhere else.

The strategy:

  1. WebP for all images by default. Encode your full image library to WebP. This covers 97% of users with fast encoding and solid compression.
  2. AVIF additionally for high-value, high-traffic images. Identify your top 10–20% of images by page views — hero images, product shots, above-the-fold content. Encode these to AVIF and serve with the <picture> pattern. The encoding cost is bounded; the bandwidth savings are significant.
  3. Measure the delta. Check your CDN transfer reports before and after AVIF deployment. On a site serving 500 GB/month in images, a 25% reduction saves ~125 GB — real money at CDN prices.

The "just use AVIF for everything" advice circulates in developer communities, and it makes sense in theory. In practice, encoding time, CDN support gaps, and animation compatibility make a blended approach more pragmatic.

How to Convert Between Formats

In the Browser

The fastest way to convert a handful of images: Pixotter's conversion tool. Drop your source image, choose WebP or AVIF as the output, and download. No upload to a server — all processing runs in-browser via WebAssembly. For one-off conversions or when you want to preview the quality before committing to a pipeline, this is the fastest path.

If your images are too large and need size reduction alongside format conversion, run them through Pixotter's compressor first to bring file sizes down before format conversion.

Command Line

WebP encoding using libwebp v1.4.0 (Apache 2.0 license):

# Standard lossy WebP at quality 80
cwebp -q 80 input.jpg -o output.webp

# Lossless WebP (for graphics with transparency)
cwebp -lossless input.png -o output.webp

# Batch encode all JPEGs in a directory
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done

AVIF encoding using avifenc from libavif v1.1.1 (BSD 2-Clause license), backed by libaom v3.9.0 (BSD 2-Clause):

# Quality 60, speed 6 (good balance of speed and compression)
avifenc --speed 6 -q 60 input.jpg output.avif

# Best compression (slow — use for pre-built assets only)
avifenc --speed 0 -q 60 input.jpg output.avif

# Faster encoding (speed 8 — 30% less compression than speed 0)
avifenc --speed 8 -q 60 input.jpg output.avif

# Batch encode with GNU parallel (4 cores, adjust -j to core count)
ls *.jpg | parallel -j 4 avifenc --speed 6 -q 60 {} {.}.avif

Build Pipeline Integration

Sharp (MIT license, v0.33.x) for Node.js — handles both formats:

const sharp = require('sharp'); // v0.33.x

// WebP
await sharp('input.jpg')
  .webp({ quality: 80 })
  .toFile('output.webp');

// AVIF
await sharp('input.jpg')
  .avif({ quality: 60, speed: 6 })
  .toFile('output.avif');

Vite (MIT license, v5.x) with the vite-imagetools plugin (MIT license, v6.x):

// vite.config.js
import { imagetools } from 'vite-imagetools'; // v6.x

export default {
  plugins: [imagetools()]
};

// Usage in component — browser picks the best format it supports
import heroAvif from './hero.jpg?format=avif&quality=60';
import heroWebp from './hero.jpg?format=webp&quality=80';

The Bottom Line

WebP is the safe default. It encodes in milliseconds, works in 97% of browsers, handles every web image type, and cuts file sizes by 25–50% compared to JPEG and PNG. If you are not using WebP today, start there.

AVIF is the upgrade for high-value images. 20–50% smaller than WebP, HDR support, and a trajectory toward faster encoding make AVIF the better long-term choice for static, pre-encoded assets. But do not replace WebP — layer AVIF on top with the <picture> element so every browser gets the best format it supports.

The practical playbook: encode everything to WebP, then additionally encode your highest-traffic images to AVIF and serve both. Measure the bandwidth impact. Expand AVIF coverage based on the data.