BlogImage Compression

AVIF vs WebP: Which Image Format to Use in 2026?

AVIF usually delivers smaller files, while WebP is faster to encode and more widely supported. Learn when to use AVIF, WebP, and JPEG fallbacks in 2026.

Updated: June 26, 2026

Use AVIF first for large photographic and LCP images, keep WebP as the fallback, and keep JPEG or PNG only for legacy compatibility or source-specific needs. In 2026, AVIF has about 93% global browser support and WebP about 96%, so the practical decision is not one format forever — it is choosing the right fallback chain and avoiding slow on-the-fly AVIF encoding. Broad Safari support arrived across Safari 16.x, with full desktop support from Safari 16.4, which removed the last major holdout. The format debate has shifted: the real question is no longer AVIF or WebP, but how to serve both cleanly with JPEG as the final safety net.

Key Takeaways

  • AVIF wins on size: typically smaller than WebP at matched visual quality, and meaningfully smaller than JPEG — most pronounced on photographic content.
  • WebP wins on encoding speed: roughly 5–10× faster to encode and far lower peak memory, which matters for real-time or large-scale pipelines.
  • Browser support is no longer a blocker: AVIF is at about 93% global support (Can I Use, 2026); WebP is at about 96%.
  • AVIF has features WebP lacks: HDR, 10/12-bit color, wide color gamut, film-grain synthesis, and larger maximum image dimensions.
  • Serve all three: AVIF → WebP → JPEG through the <picture> element, in that order — the browser picks the first format it supports.

What Actually Changed for Image Formats in 2026

Three years ago, "next-gen images" effectively meant WebP. JPEG sat atop the web at around 40% of served images. According to the HTTP Archive Web Almanac 2024 (Media chapter), JPEG has since dropped to about 32.4%, WebP climbed to roughly 12%, and AVIF — which barely registered at 0.25% in 2022 — now accounts for about 1% of web images after growing nearly 386% in two years.

Those shares are still lopsided (WebP has roughly twelve times the reach of AVIF in total image count), but the direction is clear. Cloudflare Images, Vercel Image Optimization, Shopify, and WordPress 6.5+ now serve or natively support AVIF. The ecosystem matured while most teams were still debating whether to bother.

Why this matters right now: according to HTTP Archive 2024 data, images are responsible for LCP on about 68% of mobile pages, and images make up a large share of total page weight on mobile. The median largest image on a page is around 135 KB, and the 90th percentile approaches 1 MB. Picking the right format — and serving it correctly — is one of the largest single page-speed wins available.

AVIF vs WebP: Side-by-Side Comparison

DimensionAVIFWebP
Compression vs JPEG~30–50% smaller~25–35% smaller
Compression head-to-headBetter at matched qualityTypically larger than AVIF at matched quality
Encoding speedSlower (CPU-heavy)Faster (~5–10× faster than AVIF)
Decoding speedFast in modern browsersFast; slightly faster on older hardware
Global browser support (2026)~93% (Can I Use)~96% (Can I Use)
Color depth10-bit and 12-bit8-bit only
HDR / wide color gamutYesNo
Alpha transparencyYesYes
AnimationYesYes
Film-grain synthesisYesNo
Progressive rendering in browser deliveryNot like progressive JPEGNot like progressive JPEG
Max image dimensionsVery large (spec-limited)16383 × 16383 px

AVIF is the better file format; WebP is the better pipeline format for at-scale or real-time encoding. Both are a substantial upgrade over JPEG.

File Size and Quality: Where AVIF Usually Wins

The HTTP Archive Web Almanac 2024 Media chapter measures real bits-per-pixel across millions of images. The medians come out at roughly PNG 3.8 bpp, JPEG 2.0 bpp, AVIF 1.4 bpp, and WebP 1.3 bpp — WebP slightly ahead in aggregate. That happens because early AVIF adopters skew toward photography-heavy sites that encode at higher quality settings.

In controlled tests matched on the same visual quality score (SSIM or VMAF), AVIF consistently compresses smaller than WebP — with the gap widening at low bitrates. When you push a hero image down aggressively for mobile, WebP tends to show blockiness and color banding sooner, while AVIF degrades more gracefully and preserves edges. For aggressive mobile compression, AVIF gives you more headroom before an image looks broken.

The diminishing-returns curve is worth knowing: going from an unoptimized PNG to WebP typically saves 60–70%. Going from WebP to AVIF saves a further 20–30% in most photographic scenarios. Going from AVIF at a reasonable quality to a very aggressive setting saves another 10–15% but may introduce visible artifacts. Know where to stop.

Encoding Speed: Where WebP Still Wins

This trade-off decides real-world deployments. AVIF's compression advantage comes from the AV1 codec, which is computationally expensive to encode. WebP encodes roughly 5–10× faster than AVIF at comparable quality, and AVIF encoding — especially with the libaom encoder at high quality settings — can be materially slower and more memory intensive per conversion.

When does encoding speed actually matter?

  • Real-time, on-the-fly resizing at scale — for example, serving resized user uploads immediately on request.
  • Build pipelines processing many images per minute, where slow encoding bloats deploy times.
  • Memory-constrained servers that cannot absorb the overhead of high-quality AVIF encoding.

When does it not matter? Almost every other case. If you encode once and serve from a CDN or a static build — which is most production setups — encoding time is invisible to users. Pre-encode during your build, cache the output, and AVIF's slower encoding is a non-issue.

Browser Support in 2026: AVIF Is Safe With Fallbacks

BrowserAVIF support sinceWebP support since
Chrome85 (2020)32 (2016)
Firefox93 (2021)65 (2019)
Safari / iOS SafariSafari 16.x (broad); full desktop from 16.414 (2020)
Edge121 (2024, fully)18 (Chromium base)

AVIF sits at about 93% global support; WebP is at about 96% (Can I Use, 2026). The gap is a few percentage points and narrows as older iOS devices age out. The remaining AVIF gap is mainly pre-16.4 iOS and macOS Safari builds on devices that have not updated.

For most sites, AVIF is safe as a primary format provided you ship a WebP or JPEG fallback. The cost of a gap in support is not a broken image — it is simply the fallback format being served to a small slice of older devices.

Feature Comparison: Where AVIF Goes Further

Both formats cover the basics — lossy and lossless compression, alpha transparency, and animation. They diverge on advanced capabilities:

FeatureAVIFWebP
Lossy + losslessYesYes
Alpha transparencyYesYes
AnimationYesYes
HDR / wide color gamutYes (10/12-bit)No (8-bit only)
Film-grain synthesisYesNo
Max dimensions above 16383 pxYes (spec allows much larger)No
Progressive rendering in normal browser deliveryNot like progressive JPEGNot like progressive JPEG

If you work with HDR content, product photography with subtle gradients, wide-gamut color, or images wider than 16383 px, AVIF is the only practical option of the two. For everyday web imagery — blog photos, thumbnails, UI graphics — both formats do the job, and the choice comes down to file size versus encoding cost.

A note on animation: neither format is ideal for large or long animated content. Short, small animated stickers are fine in WebP. For anything substantial, a video format (MP4/WebM) is lighter and more reliable.

Best Format by Use Case

Content typeRecommended formatNotes
Hero / LCP photographic imageAVIF → WebP → JPEGPre-encode; every byte counts for LCP
Product photographyAVIF → WebP → JPEGAVIF's advantage is largest on photos
Blog editorial photosAVIF → WebP → JPEGSame fallback chain
Screenshots with textWebP lossless or PNGSharp edges compress poorly in AVIF lossy
Logos and iconsSVG (first choice) or PNGVector is almost always better
UI graphics / small thumbnailsWebPSize difference vs AVIF is marginal; simpler
Short animations / stickersWebPKeep animations small either way
Real-time user-upload resizingWebPAVIF encoding cost is prohibitive on-the-fly
HDR or wide-gamut imagesAVIFOnly format of the two that supports HDR
Email templatesJPEG or PNGEmail clients have very limited modern format support

When to Use AVIF vs When to Stick With WebP

Use AVIF as your primary format when:

  • You pre-encode images and serve from a CDN or static build — slow encoding is invisible to users.
  • Every kilobyte matters for LCP, or you serve users on slow mobile connections.
  • Your content is photographic: hero images, editorial photography, product shots.
  • You need HDR, wide color gamut, or images wider than 16383 px.

Stick with WebP (at least as your workhorse format) when:

  • You resize or encode images in real time at scale.
  • Your build pipeline is sensitive to encoding time or memory.
  • You want the simplest possible setup with near-universal support and predictable behavior.
  • You handle large volumes of small UI graphics where the AVIF size advantage is marginal.

For most teams, the answer is not "pick one." It is "AVIF first, WebP second, JPEG as the floor."

What About JPEG XL?

You may have seen JPEG XL pitched as the next step beyond both AVIF and WebP. Technically it is impressive — it offers lossless JPEG recompression and progressive decoding that neither AVIF nor WebP provide. But the practical reality in 2026 is that JPEG XL lacks broad default support across mainstream browsers and common web image pipelines: Can I Use puts global support at around 14%, largely partial, and no major browser ships full default support. JPEG XL may become relevant in the future, but building a production image pipeline on it today is not practical. The decision that actually matters right now is AVIF versus WebP.

How to Serve Both Formats (and Protect Your LCP)

Format choice is one lever. How you serve the format is the lever most teams underuse. The standard pattern is the <picture> element, with sources listed in priority order — the browser picks the first format it supports:

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1200.avif 1200w"
          sizes="(max-width: 800px) 100vw, 800px">
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1200.webp 1200w"
          sizes="(max-width: 800px) 100vw, 800px">
  <img src="hero-800.jpg" alt="A clear description of the image"
       width="800" height="450" fetchpriority="high">
</picture>

And add a preload in the document <head> for your LCP image:

<link rel="preload" as="image" type="image/avif"
      href="hero-800.avif" fetchpriority="high">

Four rules that quietly decide whether this works:

  1. AVIF goes first. The browser picks the first source it supports. If WebP is listed first, modern browsers never reach the AVIF source.
  2. Always set the type attribute. Without it, the browser may guess wrong and download the fallback, wasting bytes.
  3. Always set width and height. This reserves layout space and prevents Cumulative Layout Shift (CLS), a separate Core Web Vitals metric.
  4. Add fetchpriority="high" to your LCP image and pair it with a <link rel="preload"> in the document head — this is the single highest-impact LCP change on most sites.

For responsive delivery, the srcset with a few sensible breakpoints (for example, 480w, 800w, 1200w, 1600w) and a matching sizes attribute tells the browser which file to fetch for each viewport. Four breakpoints cover phones through desktops — you do not need more.

Lazy-load everything below the fold with loading="lazy", but never lazy-load the LCP image. The hero should load eagerly with high priority.

One shortcut: if your CDN supports content negotiation (Cloudflare Images, Vercel Image Optimization, and similar services do), you can often skip the <picture> element. A single <img> tag is enough, and the CDN serves the right format based on the browser's Accept header — less markup, same result.

Implementation Checklist

Before you roll out a format change, work through this checklist:

  • AVIF <source> is listed before WebP in every <picture> block
  • Every <source> has a type attribute (image/avif, image/webp)
  • Every <img> has explicit width and height attributes
  • srcset breakpoints and a matching sizes attribute are set
  • LCP image has fetchpriority="high" and a matching <link rel="preload">
  • LCP image does not have loading="lazy"
  • All below-the-fold images have loading="lazy"
  • MIME types on the server are correct: image/avif and image/webp
  • AVIF and WebP files are pre-encoded and cached — not generated on each request

Mistakes That Quietly Wipe Out Your Gains

  • Listing WebP before AVIF in <picture> sources — modern browsers take the first match and never reach AVIF.
  • Omitting type attributes — the browser may pick the wrong source and waste a request.
  • Using srcset without sizes — the browser cannot calculate which resolution to fetch without it.
  • Lazy-loading the LCP image — the most common single LCP mistake; the hero image should always load eagerly.
  • Forgetting width and height — causes layout shift and damages CLS even when the format is perfect.
  • Serving a 2000 px image to a 400 px viewport — the real bottleneck is usually over-sized images, not the format. A correctly sized WebP beats a wrongly sized AVIF.
  • Re-optimizing images that are already small — a small, already well-compressed JPEG may save only a handful of kilobytes as AVIF. If you have no existing format pipeline, that saving rarely justifies the added complexity.

What to Test Before Switching Formats

Confirm the pipeline works end to end before shipping:

  1. Open DevTools → Network, filter by Img, and reload. Confirm modern browsers receive .avif and older browsers fall back to .webp or .jpg.
  2. Check the Content-Type header on served images — AVIF should be image/avif, WebP image/webp. A wrong MIME type breaks some browsers even when the file decodes locally.
  3. Run Lighthouse and check the "Serve images in next-gen formats" and "Properly size images" audits.
  4. Measure LCP in the field through Chrome UX Report or PageSpeed Insights — real-user data is what Core Web Vitals scores are based on, not lab runs alone.
  5. Spot-check the LCP element in a throttled profile (e.g., slow 4G) to confirm the hero loads as AVIF with high priority.

Next Steps

Start with the LCP image on your highest-traffic template — that single change captures most of the available win. Convert it to AVIF and WebP, wire up the <picture> element with fetchpriority="high" and a <link rel="preload">, set explicit dimensions, then roll the pattern across hero images, product photos, and editorial imagery. Leave small, below-the-fold, already-optimized images alone — they do not affect LCP and the savings are marginal.

For tooling: if you do not want to script a build pipeline with sharp, cwebp, or avifenc by hand, LessMB is a browser-based option that compresses image files locally in your browser — without uploading to a server — and lets you choose output formats such as WebP or AVIF. That is useful for one-off publishing assets or privacy-sensitive images that should not pass through a cloud queue. For comparing quality against file size on a single image, Squoosh runs AVIF and WebP encoders in the browser via WebAssembly and is the fastest way to see the quality-versus-size trade-off for your own photos.

FAQ

Which is smaller, AVIF or WebP?

AVIF. In controlled tests matched on the same visual quality, AVIF files are typically smaller than WebP — with the gap most pronounced on photographic content at low bitrates. Both still beat JPEG by a wide margin.

Is AVIF supported by all browsers in 2026?

AVIF has about 93% global browser support across Chrome, Firefox, Edge, and Safari 16.x, with full desktop support from Safari 16.4. The remaining gap is mostly older iOS devices that have not updated. With a WebP or JPEG fallback in the <picture> element, AVIF is safe as a primary format for most sites.

Which format is better for SEO and Core Web Vitals?

Search engines do not directly reward image formats. What improves Core Web Vitals is LCP speed, which depends on file size, correct width/height attributes, fetchpriority on the hero image, and right-sized responsive delivery. AVIF gives you the smallest LCP bytes on photographic content, which helps on image-heavy pages — but serving the right size is usually a bigger lever than format alone.

When should I stick with WebP instead of AVIF?

When encoding speed is on the critical path: real-time resizing at scale, or build pipelines processing many images per minute where AVIF encoding cost is prohibitive. WebP encodes roughly 5–10× faster and uses far less memory per conversion.

Should I serve both AVIF and WebP at the same time?

Yes. Use the <picture> element with an AVIF source first, a WebP source second, and a JPEG <img> fallback. The browser picks the first format it supports, so modern browsers get AVIF and older browsers degrade gracefully.

Does WebP support HDR or 10-bit color?

No. WebP is limited to 8-bit color depth. AVIF supports 10-bit and 12-bit depth, HDR, and wide color gamut — important for product photography with subtle gradients or any HDR publishing workflow.

Should I convert every image to AVIF?

No. Focus on LCP and hero images first — that is where byte savings directly improve Core Web Vitals scores. Small UI graphics, screenshots with text, SVG-suitable logos, and images already under 20 KB rarely justify the added encoding complexity.

Is WebP still worth using in 2026?

Yes. WebP is the right fallback for browsers without AVIF support, and the better choice for real-time image pipelines where AVIF encoding cost is prohibitive. The <picture> element pattern means you can serve AVIF to modern browsers and WebP to everyone else without choosing one over the other permanently.

Is AVIF good for screenshots or logos?

Screenshots with text typically compress more cleanly as WebP lossless or PNG, where sharp edges and flat colors are preserved. Logos and icons are almost always better served as SVG. AVIF's advantage is most pronounced on photographs and natural images with gradients.

Sources