Skip to content

Image Formats

WebP vs AVIF in 2026 — Which to Use and When

WebP and AVIF are both worth shipping in 2026, but they solve different problems. Here's the practical comparison — compression, support, encode speed, fallbacks.

By 2026 the “which modern image format should I use” debate has settled into a stable answer: use both, and use them for different things. WebP is the reliable workhorse, universally supported and fast to encode. AVIF gives you better compression at the cost of encode time and slightly more fallback work. This guide walks through the real trade-offs so you can pick without re-reading a benchmark blog.

Browser support, the short version

WebP is supported in every evergreen browser and has been since 2020. You can ship a WebP file today without a PNG or JPG fallback and reach >98% of global traffic. The remaining fraction is mostly old devices locked out of browser updates.

AVIF is newer. Chrome added support in version 85 (August 2020), Firefox in version 113 (May 2023), and Safari in 16.4 (March 2023). By 2026, AVIF coverage is around 95% of global traffic — close to WebP but not there yet. The gap matters only if you care about the last few percent.

FormatChromeFirefoxSafariEdgeCoverage 2026
WebP32 (2014)65 (2019)14 (2020)18 (2020)>98%
AVIF85 (2020)113 (2023)16.4 (2023)121 (2024)~95%

The safe pattern is <picture> with AVIF first, WebP second, JPG/PNG fallback last. Browsers pick the first one they support, so you pay nothing extra.

Compression, in real numbers

Benchmarks vary wildly depending on the source image and the encoder settings, but a reasonable rule of thumb for photographic content at visually equivalent quality:

  • JPG baseline: 100 KB
  • WebP lossy: 65-75 KB (25-35% smaller)
  • AVIF: 45-60 KB (40-55% smaller)

For graphics with large flat areas or text, the numbers shift:

  • PNG baseline: 100 KB
  • WebP lossless: 75-80 KB (20-25% smaller)
  • AVIF lossless: 65-75 KB (25-35% smaller)

AVIF wins on virtually every content type, but the absolute gap shrinks at higher quality levels. At quality 95+, AVIF’s lead over WebP narrows to 10-15%. The win is biggest in the 60-80 quality range — exactly where most web images should be.

Encode speed, which nobody talks about

The reason AVIF isn’t just a straight upgrade is encode time. AVIF is built on the AV1 video codec, which was designed to produce small files at any cost in encoding compute. WebP is based on VP8, an older and faster codec.

At default settings in most encoders:

  • WebP encodes in roughly 100-300 ms per megapixel on a modern CPU.
  • AVIF encodes in roughly 1-4 seconds per megapixel on the same CPU, depending on effort level.

This matters when you’re converting in bulk, running a build-time image pipeline, or doing client-side encoding. If your CI already takes 4 minutes, adding AVIF to every image in a 500-image site might push that to 10-15 minutes. That’s usually fine, but it’s worth knowing before you flip the switch.

For one-off conversions like JPG to WebP or PNG to WebP, the difference is invisible — you’re waiting a fraction of a second either way.

When to use each

Use WebP when:

  • You need a single modern format, no fallback chain.
  • You’re encoding many images at build time and encode speed matters.
  • You need universal support with no <picture> tag complexity.
  • You’re shipping images that update frequently (user-generated content).

Use AVIF when:

  • The image is content — product shots, editorial hero images, portfolio work — where the extra compression is worth the engineering effort.
  • You already have a <picture> tag setup.
  • Images are long-lived and the one-time encode cost amortizes over millions of views.
  • Bandwidth matters more than encode time (mobile-first, emerging markets).

Ship both when you’re building a production site and want the best balance. The <picture> tag makes this trivial:

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

Browsers that understand AVIF grab the AVIF. Browsers that understand WebP but not AVIF fall through to WebP. Everything else falls through to JPG. Cost to you: three files instead of one, and a bit more markup.

Transparency and animation

Both formats support transparency (alpha channel). AVIF’s alpha compression is meaningfully better — often 30-40% smaller than WebP at equivalent quality, which matters for cutouts, product shots on transparent backgrounds, and icons.

Both support animation as a lossy alternative to GIF. AVIF has better compression; WebP has wider support. For most animation use cases in 2026, the right answer is a real video element with <video> and MP4/WebM sources — animated images are a niche tool now, useful mostly for email where <video> doesn’t work.

The conversion workflow

A typical workflow looks like this:

  1. Source: raw photo at camera resolution (often 24 MP / ~8 MB JPG).
  2. Resize to delivery size (e.g., 2000 px max width for hero, 800 px for thumbnails).
  3. Encode to WebP at quality 80.
  4. Encode to AVIF at quality 60-70 (AVIF’s quality scale is not the same as WebP’s; quality 65 AVIF is roughly equivalent to quality 80 WebP).
  5. Generate a JPG fallback at quality 82.
  6. Ship all three with a <picture> tag.

You can handle any step of this chain with the OpenImages browser tools — JPG to WebP, PNG to WebP, WebP to JPG for the fallback, and Compress Image for the final byte squeeze. Everything runs locally, so a product shot under embargo never touches a third-party server.

What to skip

A few things people worry about that don’t actually matter:

  • JPEG XL. Great format on paper. Chrome removed support in 2023 and hasn’t added it back as of 2026. Don’t ship JXL to production; it’s a dead end on the web.
  • HEIC/HEIF. Apple’s default camera format. Great compression, zero browser support outside Safari. Convert HEICs to JPG or WebP for delivery.
  • Quality = 100. On both WebP and AVIF, quality 100 disables some of the perceptual coding that makes these formats good. Use quality 85-90 as a realistic upper bound.

The summary: in 2026, WebP is the default, AVIF is the optimization, and a <picture> tag gives you both with a JPG safety net. That combination ships smaller pages, faster loads, and better Core Web Vitals than anything a single-format strategy can produce.

Related tools

Frequently asked questions

Which has wider browser support in 2026, WebP or AVIF?

WebP has the edge. It's been supported in every evergreen browser since 2020 and reaches >98% of global traffic with no fallback. AVIF arrived later — Chrome 85 in 2020, Safari 16.4 in 2023, Firefox 113 in 2023 — and by 2026 covers around 95% of global traffic. The gap is small enough that if you use a picture tag with AVIF first and WebP second, every user gets the best format their browser supports and you pay nothing extra.

Should I serve both AVIF and WebP with a picture fallback?

Yes, for production sites this is the standard pattern. Put AVIF first, WebP second, and a JPG or PNG inside the img tag as the final fallback. Browsers pick the first source they support, so AVIF-capable browsers get the smallest file, WebP-capable browsers fall through to the second, and anything older gets the universal fallback. The cost is three files instead of one plus a few extra lines of markup — trivial next to the bandwidth savings.

When does AVIF encoding take too long to be worth it?

AVIF encodes in roughly 1-4 seconds per megapixel versus 100-300 ms for WebP on the same CPU. For one-off conversions the difference is invisible, but for build-time pipelines on sites with hundreds of images it adds up. If your CI takes 4 minutes for WebP, adding AVIF might push it to 10-15 minutes. That's usually fine for long-lived images where the encode cost amortizes across millions of views, but skip it for frequently changing user-generated content.

Is quality 100 in WebP or AVIF a good idea?

No. Quality 100 on both WebP and AVIF disables some of the perceptual coding that makes these formats efficient, so you get bigger files without visible quality gain. Use quality 85-90 as a realistic upper bound. For most web content, WebP 80 or AVIF 60-70 is the sweet spot — AVIF quality 65 is roughly equivalent to WebP quality 80 in visible output, because the two scales are calibrated differently.

Should I bother with JPEG XL in 2026?

Not for the web. JPEG XL is a strong format on paper but Chrome removed support in 2023 and has not reinstated it as of 2026. Without Chrome coverage it's a dead end for production. Stick with WebP plus AVIF plus a JPG fallback in a picture tag — that combination ships smaller pages and better Core Web Vitals than any single-format strategy and doesn't depend on a niche codec.

Sponsored