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:
- Alpha channel transparency — full 8-bit alpha, works in both lossy and lossless modes
- Animation — frame-by-frame animation with full color depth (24-bit vs GIF's 8-bit)
- Metadata — EXIF and XMP embedding
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:
- HDR and wide color gamut — 10-bit and 12-bit color depth, Rec. 2020 and DCI-P3 color spaces, PQ and HLG transfer functions. HDR images in AVIF retain luminance headroom that WebP loses at 8-bit.
- Film grain synthesis — encode film grain as metadata rather than data, reducing file size for grainy images
- Progressive decoding (via sequences) — AVIF sequences can deliver a low-resolution version first
- Lossless mode — less common than WebP lossless but available
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:
- User-generated content platforms — images are uploaded constantly, must be processed quickly
- Dynamic resizing pipelines — on-demand image transforms where latency matters
- Real-time applications — screen sharing, video conferencing, live media
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:
- Speed of encoding matters. CI/CD pipelines, user uploads, real-time image processing, or any workflow where encoding time affects latency or throughput.
- Your CDN handles image transforms. Most CDNs serve WebP from JPEG/PNG originals on-the-fly. AVIF transform support is less universal and often slower.
- You want maximum compatibility. 97% browser coverage, universal toolchain support, no edge cases.
- You are replacing JPEG or PNG for standard web content. Hero images, thumbnails, blog post images, UI assets — WebP covers all of these well.
- Animation is needed. Animated WebP is widely supported; animated AVIF is still catching up.
- Build-time constraints exist. Short CI budgets or small build servers make AVIF batch encoding impractical.
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:
- Maximum compression is the priority. High-traffic pages where bandwidth cost is measurable — e-commerce category pages, news homepages, large media galleries. A 20% reduction in image bytes translates to lower CDN costs and better LCP at scale.
- HDR content is in your pipeline. AVIF is the only web format that correctly handles 10-bit and 12-bit HDR imagery with PQ or HLG transfer functions. If you are serving content for HDR displays, AVIF is the only format that preserves what you shot.
- Encoding is a one-time cost. Static marketing sites, landing pages, or blog posts where images are set once and rarely change — encoding time is front-loaded and amortized across thousands of page views.
- You have encoding hardware to spare. AVIF parallelizes well across CPU cores. An 8-core server cuts encoding time roughly in half. GPU-accelerated AV1 encoders (Intel Arc, AMD RDNA 3+, NVIDIA Ada) reduce it further.
- You are forward-building. AVIF's trajectory is positive —
libaomencoders get faster with every release.
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:
- WebP for all images by default. Encode your full image library to WebP. This covers 97% of users with fast encoding and solid compression.
- 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. - 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.