WebP vs AVIF Encoding: Browser Support, Size & Speed

Choosing between WebP vs AVIF in 2026 is no longer about browser support — both formats now render almost everywhere. The real trade-off has moved to the encoding side: AVIF produces noticeably smaller files, but it makes you pay for them in CPU time. This guide covers the current support matrix, realistic file-size expectations, and what the speed dials on cwebp and avifenc actually do, so you can pick the right format per image instead of by habit.

#TL;DR

• AVIF reaches Baseline Widely Available on 2026-07-25; WebP has been universal since 2020.
• Lossy AVIF is typically 20–40% smaller than WebP on photos.
• Lossless flips the result: WebP usually beats lossless AVIF.
• AVIF encoding is several times slower; presets control the trade-off.
• Best practice: serve AVIF with a WebP fallback via <picture>.

#Is AVIF supported in all browsers in 2026?

For practical purposes, yes. Per the web-features browser support data, AVIF became Baseline Newly Available on 2024-01-25 — the day the last major engine shipped it — and is expected to reach Baseline Widely Available on 2026-07-25. That second milestone matters: it marks 30 months of support across Chrome, Edge, Firefox, and Safari, the point where most teams stop worrying about fallbacks entirely.

#When each browser shipped AVIF

Two footnotes worth knowing. Firefox actually rendered still AVIF images from version 93 in late 2021 — version 113 is when animated AVIF landed, which is what the full-support date tracks. And Edge was the curious laggard: despite sharing Chromium's engine, it shipped AVIF more than three years after Chrome did.

#What about WebP support?

WebP cleared this bar long ago. Chrome has decoded it since 2014, Firefox since 2019, and Safari 14 closed the loop in 2020. If your audience uses any browser released this decade, WebP simply works — which is exactly why it remains the fallback format of choice.

#Do you still need a WebP fallback for AVIF?

Until the July 2026 widely-available date passes — and for a while after, if your analytics show long-tail traffic from older iOS or enterprise Edge installs — yes. The cost is one extra <source> line, and the failure mode without it is a broken image, not a slower one. Keep the fallback.

#How much smaller is AVIF than WebP?

Size is where AVIF earns its CPU bill, but the gap depends heavily on image content and on whether you're encoding lossy or lossless.

#Photos and gradients: where AVIF pulls ahead

For lossy photographic content, AVIF consistently wins. MDN's image format guide cites a comparison in which AVIF achieved roughly 50% compression against a JPG test set where WebP managed about 30%. In day-to-day conversion work, expect AVIF output to land 20–40% below the equivalent WebP on photos, with the biggest wins on smooth gradients, skies, and skin tones — content where AV1's larger prediction blocks and directional modes shine. You can verify this on your own images in about a minute: drop the same photo into the iKit Image Format Converter twice, export once as WebP and once as AVIF at comparable quality, and compare the byte counts. Nothing uploads — the encoding runs in your browser.

#Flat graphics and screenshots: closer than you think

On UI screenshots, logos, and flat illustrations the formats converge. Hard edges and large solid areas compress well under both codecs, so the AVIF advantage often drops to single-digit percentages — sometimes WebP even comes out ahead at fast AVIF speed presets. For this content class, encoding time becomes the deciding factor, and WebP's near-instant encode is hard to argue with.

#Lossless mode: WebP usually wins

Lossless is the reversal almost nobody expects. WebP's dedicated lossless mode — a purpose-built design using prediction, color caching, and LZ77 — routinely produces files about 26% smaller than PNG, per MDN's figures. AVIF's lossless mode, by contrast, is a bolted-on configuration of a lossy video codec and frequently produces larger files than lossless WebP. If you need pixel-exact output (screenshots with text, line art, pixel art), encode lossless WebP and skip AVIF entirely.

One structural limit to remember: WebP caps out at 16,383 × 16,383 pixels and stores lossy data as 8-bit 4:2:0 only. AVIF handles 10- and 12-bit depth, HDR, and wide color gamut — if those matter to you, the size debate is already over.

#Why is AVIF encoding so slow?

AVIF inherits its compression from AV1, a video codec designed on the assumption that you encode once and stream millions of times. The encoder evaluates an enormous decision tree — variable block partitions, dozens of intra-prediction modes, multiple transform types — for every region of the image. WebP's VP8-derived encoder searches a far smaller space. The size savings are real, but they are literally purchased with CPU cycles.

#What avifenc speed 0–10 actually changes

The reference encoder's avifenc documentation exposes a --speed setting from 0 (slowest) to 10 (fastest), defaulting to 6. Lower numbers let the encoder explore more of that decision tree:

# balanced default (speed 6)
avifenc -q 60 photo.png photo.avif

# slow but ~5-10% smaller output
avifenc -q 60 --speed 2 photo.png photo.avif

# fast preview-quality encode
avifenc -q 60 --speed 9 photo.png photo.avif

At speed 2 and below, encode times grow to many times the default — fine for a build pipeline that runs nightly, painful for anything interactive. Speeds 8–10 encode quickly but give back a meaningful slice of AVIF's size advantage.

#cwebp -m 0–6: WebP's speed dial

WebP has the same concept with a smaller range. Google's cwebp encoder documentation defines -m from 0 to 6 with a default of 4 — higher means more effort, smaller files:

# default effort (-m 4), quality 75
cwebp -q 75 photo.png -o photo.webp

# maximum effort, still fast in practice
cwebp -q 75 -m 6 photo.png -o photo.webp

The practical difference: even cwebp -m 6 finishes in a fraction of the time a default AVIF encode takes on the same image. Expect AVIF to run several times slower than WebP at default settings on both, and up to an order of magnitude slower at aggressive presets — the exact ratio varies with image size, content, and encoder version, so benchmark on your own corpus before wiring either into a hot path.

#Decode speed matters too

Encoding happens once; decoding happens on every page view. AVIF decode is also heavier than WebP decode, and AVIF has a second cost MDN calls out explicitly: it doesn't support progressive rendering, so the browser shows nothing until the file has fully arrived. Smaller files offset much of this on slow networks, but on large hero images the absence of progressive display is visible. WebP decodes incrementally and lightly — one reason it remains the safer choice for above-the-fold imagery on low-end devices.

#Should I use AVIF or WebP in 2026?

Stop thinking format-versus-format and start thinking per-image-class. Here is the decision in table form:

#Serve both with the picture element

The pattern that makes the choice safe — browsers walk the sources top-down and take the first format they support:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Product hero"
       width="1200" height="630">
</picture>

A few rules that keep this airtight:

• Always include type on each <source> so the browser can skip formats without fetching them.
• Keep the <img> fallback last — it's also where alt, width, and height belong.
• Generate the variants in one pass: resize first, then encode each format from the same master, never from another lossy output.

#A realistic batch workflow

For a typical site refresh: export your masters as PNG, resize them to final display dimensions with the iKit Image Resizer, then batch-convert the set to AVIF and WebP in the browser. If some sources are oversized photos straight off a camera, run them through the iKit Image Compressor first and download the whole batch as a ZIP. Every step runs client-side, so the workflow works the same for a marketing site and for images you'd rather not upload anywhere.

#When to skip AVIF entirely

Skip AVIF when you encode on demand (user uploads, CMS thumbnails on a small server) and CPU time is your bottleneck; when your images are mostly flat graphics where the savings are marginal; or when you need lossless output. In those cases WebP alone — universal, fast, predictable — is the better engineering decision, and you can revisit AVIF when your pipeline moves encoding off the request path.

#References

• Web platform features explorer — AVIF — Baseline status dates and per-browser AVIF support versions.
• Image file type and format guide — MDN — WebP/AVIF size figures, WebP dimension and bit-depth limits, AVIF progressive-rendering note.
• cwebp — WebP — Google for Developers — -m 0–6 method range, -q default, and lossless options used in the examples.
• libavif avifenc.1.md — AOMediaCodec/libavif — --speed 0–10 range and default speed 6 for the reference AVIF encoder.

#Related on iKit

• Convert Images to AVIF — and When AVIF Beats WebP — the hands-on conversion walkthrough that pairs with this comparison's benchmarks.
• PNG vs JPG vs WebP vs AVIF: Which Should You Use? — the full four-format decision guide if you're still choosing a baseline format.
• Convert PNG to WebP and Cut Image Size by 30% — deep dive on the WebP side, including lossless mode and cwebp recipes.
• How to Convert JPG to PNG (and When You Shouldn't) — why converting between lossy and lossless formats can backfire.
• Convert PNG to JPG Without a Black Background — handling transparency when you must target a format without an alpha channel.
• How to Compress PNG Images Without Losing Quality — shrinking the lossless masters you'll feed into your WebP/AVIF pipeline.