WebP vs AVIF

The short answer

WebP and AVIF are both modern web image formats, both lossy-or-lossless capable, both supported by the major browsers, both backed by industry consortia. The headline difference: AVIF produces 20–30% smaller files than WebP at equivalent visual quality, at the cost of dramatically slower encoding and slightly slower decoding on low-end devices.

For sites that already ship WebP, adding AVIF on top is a marginal performance improvement (5–15% off the WebP baseline) with non-trivial cost in encoding time and pipeline complexity. For new sites or sites where image weight is a binding constraint, the AVIF-first stack with WebP fallback is the modern frontier. For sites where build pipelines or mobile decoder performance matter, WebP alone is often still the right answer.

The two formats coexist; the right choice is context-dependent.

Origins

WebP was developed by Google in 2010, based on the VP8 video codec from Google's acquisition of On2 Technologies. The intent was a single replacement for both JPG (lossy photographic) and PNG (lossless graphics), with the bonus of animation and full alpha support.

AVIF (AV1 Image File Format) was specified by the Alliance for Open Media in 2019. It's the still-image counterpart to the AV1 video codec, developed by a consortium including Google, Mozilla, Microsoft, Cisco, Intel, Netflix, Amazon, and Apple. AV1 itself was designed as the successor to VP9 and HEVC, with a higher compression ceiling than either.

The lineage matters. WebP's compression is good for a 2010 still-image format derived from a 2008 video codec. AVIF's compression is good for a 2019 still-image format derived from a 2018 video codec. The decade of codec progress accounts for most of AVIF's compression advantage.

For full format detail, see WebP format overview and AVIF Format.

Where AVIF wins

File size

The headline win. On photographic content at equivalent visual quality, AVIF typically produces files 20–30% smaller than WebP. The advantage is more pronounced at lower bitrates (heavily compressed thumbnails) and smaller at higher bitrates (archival-quality hero imagery).

Rough relationships for typical photographic content:

The AVIF win is real but the absolute deltas are smaller than the WebP-over-JPG win that came before. The first migration step (JPG → WebP) typically saves 30%; the second step (WebP → AVIF) typically saves a further 20%.

HDR and wide colour gamut

AVIF natively supports 10-bit and 12-bit per channel encoding with HDR transfer functions and wide-gamut colour spaces (BT.2020, Display P3, Rec. 2100 HLG and PQ). WebP is 8-bit-per-channel only.

For HDR content delivery — high-end product photography, cinematic content, photography aimed at modern HDR displays — AVIF is the only meaningful web option. WebP can't carry the dynamic range.

Future trajectory

AVIF support is improving faster than WebP support is regressing. AVIF browser support reached production levels in 2022 (Safari 16 was the last major browser to ship it) and continues to widen. AVIF encoder performance is improving year over year as implementations mature. The format is the cleaner long-term bet.

Where WebP wins

Encoding speed

AVIF encoding is dramatically slower than WebP encoding — often 10–50× slower at equivalent quality and effort settings. A typical 1200×800 photo that takes 200ms to encode as WebP at high effort (-m 6) can take 5–20 seconds as AVIF at high effort.

For static-site build pipelines processing hundreds or thousands of images at build time, this matters. A build that took 2 minutes with WebP can balloon to 20+ minutes with AVIF. For one-time encoding of important assets (heroes, product photos), the time investment is fine; for high-volume encoding, it's painful.

Modern AVIF encoders (avifenc, rav1e) and Sharp's effort parameter offer fast modes that trade compression ratio for speed. The fast-mode AVIF files are still smaller than WebP, but the size advantage shrinks.

Decoding speed

AVIF decoding is also slower than WebP decoding, particularly on low-end mobile devices. The byte savings on transfer can be partially offset by longer decode times on the client.

For sites with low-end mobile audiences (significant Android traffic on older devices, emerging-markets audiences on budget phones), measure on real devices. Synthetic Lighthouse runs don't reflect the decode cost.

Browser support

WebP sits at ~97% of global browser traffic. AVIF sits at ~94–95% and closing. The gap is small but real, and it matters more in some contexts than others — older iOS devices and embedded webviews skew toward WebP support.

In practice, both formats need the same <picture> fallback pattern, and the marginal coverage difference rarely changes the decision.

Tooling maturity

WebP has been mainstream since 2014 and tooling is mature across encoders, CDNs, CMSes, build pipelines, and image editors. AVIF reached production browser support in 2022 and tooling is rapidly improving but still less polished:

• WordPress — both formats supported, but WebP plugins are more battle-tested.
• Shopify CDN — serves WebP automatically; AVIF support is more recent.
• CDN auto-conversion — Cloudflare Polish, Imgix, Cloudinary all support both, but WebP has more configuration options.
• Image editors — Photoshop, Affinity Photo, GIMP all support WebP. AVIF support is newer and less consistent across versions.

The practical pattern

For modern web delivery, the state of the art is a three-source <picture> element:

<picture>
  <source
    type="image/avif"
    srcset="
      /img/photo-800.avif 800w,
      /img/photo-1200.avif 1200w,
      /img/photo-1800.avif 1800w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <source
    type="image/webp"
    srcset="
      /img/photo-800.webp 800w,
      /img/photo-1200.webp 1200w,
      /img/photo-1800.webp 1800w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <img
    src="/img/photo-1200.jpg"
    srcset="/img/photo-800.jpg 800w, /img/photo-1200.jpg 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
    alt="..."
    width="1200"
    height="675"
    loading="lazy"
    decoding="async"
  />
</picture>

The browser picks the first format it supports. AVIF-capable browsers get AVIF; WebP-capable browsers get WebP; everyone else gets JPG. No JavaScript required.

The cost: you ship three encoded variants per image at multiple resolutions. For a typical 4-width responsive image, that's 12 files per source image. Storage and build time scale linearly.

For sites where the cost is acceptable (image CDN handles encoding, or the asset count is manageable), this is the modern default. For sites where the cost is significant, WebP-only with JPG fallback is still a defensible choice.

When to ship AVIF

Ship AVIF when:

• The site is performance-critical and the marginal byte savings matter (ecommerce above-the-fold, image-heavy publishing, mobile-first audiences).
• Your image pipeline is CDN-based (Cloudflare Images, Cloudinary, Imgix, Vercel) — the CDN handles encoding cost for you.
• The site has HDR content (10-bit or 12-bit colour) that WebP can't represent.
• The build pipeline can absorb the encoding time, or pre-existing encoded variants live in a CDN.

When to skip AVIF

Skip AVIF (ship WebP-only with JPG fallback) when:

• The build pipeline encodes images at build time and AVIF would meaningfully slow down builds.
• Your audience skews toward low-end mobile devices where decode cost may offset transfer savings.
• The site already ships WebP and the marginal improvement isn't worth the pipeline complexity.
• You're early in a project and AVIF is something to add later when the rest of the stack is settled.

Encoding parameters

For WebP, see WebP Compression Settings. The recommended baseline is -q 80 -m 6 for lossy, -lossless -z 9 for lossless.

For AVIF, the equivalent baseline:

# Standard encoding
avifenc --speed 4 --min 30 --max 50 input.jpg output.avif

# Faster encoding for build pipelines
avifenc --speed 8 --min 30 --max 50 input.jpg output.avif

The --speed parameter accepts 0–10. Lower is slower and produces smaller files; higher is faster and produces larger files. The --min / --max quality range typically maps to a visual quality similar to WebP q=78–82.

For Sharp-based Node pipelines:

import sharp from "sharp";

await sharp("source.jpg")
  .resize({ width: 1200, withoutEnlargement: true })
  .avif({ quality: 50, effort: 6 })
  .toFile("output.avif");

AVIF's quality scale is different from WebP's — AVIF q=50 is roughly equivalent to WebP q=78. The scales aren't 1:1.

Recommendation

For new sites: ship AVIF as primary, WebP as fallback, JPG as final fallback. The full <picture> pattern. Accept the build pipeline cost.

For existing WebP-only sites: assess whether the marginal byte savings justify the pipeline change. Often the bigger wins are elsewhere — image dimensions, lazy loading, LCP optimisation. See WebP Optimisation and Core Web Vitals & Images.

For HDR content specifically: AVIF is the only meaningful web option. WebP isn't suitable.

For static-site generators with thousands of images: measure build time honestly. If AVIF encoding doubles your build time and the saving is 8% per image, the tradeoff may not be worth it.

Common questions

Will AVIF replace WebP?

Over a 5–10 year horizon, probably yes — AVIF is the cleaner long-term bet. In the next 2–3 years, both coexist because WebP's tooling and decoder maturity still matter for many use cases.

Is AVIF compatible with WebP?

The formats are unrelated technically. AVIF is based on AV1; WebP is based on VP8. They share the <picture> element delivery pattern but require separate encoding and produce separate files.

Why is AVIF so much slower to encode?

AV1 (and AVIF) was designed for maximum compression efficiency rather than encoding speed. The codec has many more prediction modes and transform options than VP8 (WebP's basis). The encoder has more decisions to make per block, which takes time.

Does AVIF compress better than JPEG XL?

JPEG XL has different design priorities (lossless recompression of existing JPEGs, progressive decoding) and is competitive with AVIF on raw compression. But JPEG XL never gained browser support — Chrome shipped it briefly then removed it in 2022. AVIF is the realistic web option for next-generation compression.

Should small sites worry about AVIF?

If your site has fewer than a few dozen images and you have a CDN that auto-converts (Cloudflare Polish, Cloudinary, Imgix), enabling AVIF is approximately free. Do it. If you build images at build time and adding AVIF doubles your build, weigh the trade-off honestly.

Further reading

• WebP format overview — technical detail on WebP
• AVIF Format — technical detail on AVIF
• WebP vs JPG — the baseline migration that often matters more
• JPG vs AVIF — direct AVIF-vs-legacy comparison
• WebP Optimisation — broader performance walkthrough
• WebP Compression Settings — encoder parameter reference
• Core Web Vitals & Images — measuring real-world impact