WebP vs AVIF in 2026: Which Modern Image Format Wins?

The answer is neither, and both. That is not a cop-out — it is the only honest position after running conversions on thousands of real images. WebP and AVIF solve slightly different problems, have different cost structures, and trip over different edge cases. Picking one for every use case is how you end up with bloated encode pipelines or unsupported browsers in your analytics.

This guide cuts through the marketing comparisons and looks at the trade-offs that actually matter when you are choosing a format for a production site in 2026. We will cover file size on real images (not synthetic benchmarks), browser support, encoding time, quality at typical settings, and the <picture> fallback strategy that most teams end up at.

The quick verdict

If you need a single sentence to guide a decision: use AVIF for hero images and photographs where file size matters most, WebP for everything else because its encoder is faster and support is universal. Ship both with a JPEG fallback. That is the pattern that wins in 2026 for 95% of sites.

A brief history: why two formats exist

WebP was created by Google in 2010, based on the VP8 video codec. It landed with the promise of 25–35% smaller files than JPEG at equivalent visual quality. For years it fought browser adoption battles until Safari finally shipped support in 2020. By 2022 it was universally available and became the default "modern" format for most teams.

AVIF arrived later, derived from the AV1 video codec developed by the Alliance for Open Media. It uses the AV1 bitstream to encode still images and supports HDR, wide color gamuts, and animation. At equivalent quality, AVIF typically produces smaller files than WebP — often 20–30% smaller on photographs. That advantage comes at a steep cost in encoder time, which we will address.

The detailed Google WebP documentation and the Mozilla AVIF reference remain the authoritative sources for format internals. Everything below is the practical side.

File size: the numbers that matter

Marketing materials love to show dramatic size reductions. Real images are messier. Here is what we see consistently across a few thousand converted files:

On photographs, AVIF wins by roughly 30% over WebP. On images with lots of text or sharp edges (UI screenshots, technical diagrams), the gap narrows because both formats use block-based transforms and neither is ideal for crisp lines. For those, consider PNG-8 or SVG instead.

To run your own comparisons, JPG to WebP and PNG to WebP handle the WebP side in-browser. For AVIF, use Image Format Converter, which supports the modern formats including AVIF as a target. Run a handful of your actual production images through both, and weigh the numbers against your bandwidth costs and user device profile.

Visual quality and the weird AVIF artifacts

At default quality settings, both formats look identical to a human at normal viewing distances. Zoom in at 400%, and differences appear. WebP artifacts look like JPEG artifacts — slight ringing around edges, block boundaries in flat areas. AVIF artifacts are different: smoothing that can look like waxy skin in portraits at low bitrates, and occasional banding in gradients.

The AVIF smoothing is the one to watch out for. Encoding a portrait at AVIF q=40 will produce a smaller file than WebP q=60 but can strip fine skin texture in a way that looks subtly wrong. The fix is to nudge quality up; for photographs we recommend AVIF q=60 as the floor, q=70 for hero imagery.

If you need to inspect quality differences side by side, Image Compressor lets you preview before and after compression without any upload. Zoom in on faces, skies, and subtle gradients — the three places where low-bitrate AVIF suffers.

Browser support in 2026

WebP is universal. Every modern browser supports it, including Safari since version 14. Old IE is the only holdout, and if you still support IE in 2026, you have bigger problems.

AVIF support is more recent but also now broad. Chrome, Firefox, Safari (since 16.4), and Edge all support AVIF decoding. The caniuse AVIF data puts global support above 95% as of early 2026. The remaining gap is old Android browsers on devices that will not receive updates, and certain embedded webviews. For those, you still need a fallback.

Encoding cost and why it matters

Here is where AVIF's story gets complicated. The AV1 encoder is computationally expensive. Encoding a single 1920×1080 photograph to a good AVIF can take 5–30 seconds on a typical CPU, compared to 0.2–1 seconds for WebP. On a server, that difference compounds fast. If you are processing user-uploaded images in a serverless function, AVIF encoding will hit cold-start and timeout limits that WebP comfortably avoids.

There are faster AVIF encoders (aom-av1 with speed preset 8, svt-av1) that trade some size efficiency for speed, but even the fastest AVIF is slower than WebP. The practical rule: encode AVIF at build time for static assets, encode WebP at runtime if you need dynamic resizing. A build pipeline where hero images go through AVIF and everything else goes WebP hits both targets.

For in-browser encoding of a few images at a time, both formats work fine. Image Compressor and Image Resizer handle them client-side — no upload, no server cost, and the encoder runs at the pace your device can handle. If you need to strip EXIF metadata before publishing, Image Metadata Stripper removes GPS coordinates and camera info that modern formats carry forward from the source.

The <picture> fallback pattern

You rarely pick one format. You serve the best available to each browser using the <picture> element:

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

The browser walks the sources top to bottom and uses the first one it supports. AVIF-capable browsers get AVIF, WebP-capable ones fall back to WebP, and the JPEG is the last resort. Triple your build pipeline — each image becomes three files — but every user gets the best format their browser understands.

Do not forget the width and height attributes on the fallback <img>. They let the browser reserve layout space before the image loads, which prevents cumulative layout shift and is a factor in Core Web Vitals. See the web.dev CLS guide for the background.

Final recommendation by use case

Marketing sites with a few hero images

AVIF for heroes, WebP everywhere else, JPEG fallback. The encoder cost is manageable because you only have a handful of images. File size wins matter because hero images are typically the LCP element.

E-commerce with thousands of product images

WebP for everything, generated at build or in a pre-warmed queue. The encoder cost of AVIF across thousands of images is significant, and the marginal size win does not justify it for typical product shots on white backgrounds, which already compress well.

User-generated content platforms

WebP at upload time, AVIF asynchronously as a background job. Serve whatever is ready. The user sees their upload immediately via WebP; the AVIF version becomes available a minute later for future viewers.

Photography portfolios

AVIF at high quality (q=75+) is worth the encoder time. File size matters, photographs are the worst case for WebP, and your visitors are there to look at images — they will notice the quality difference. For aspect-ratio consistency across a grid, Aspect Ratio Calculator helps size your crops, and Image Cropper trims to the exact dimensions before conversion. Final sanity check with Image Metadata Viewer confirms that the EXIF and color-profile info survived (or was stripped) as intended.

Related pillar guide

This cluster sits under our image pillar. For the full workflow — responsive images, lazy loading, LCP, and every step in a modern image pipeline — see Image Optimization: The Complete Guide.

FAQ

What about JPEG XL?

JPEG XL is technically impressive and fits nicely between the WebP and AVIF trade-off curves, but browser support has been a moving target. Chrome removed its experimental support, Firefox ships it behind a flag, and Safari added it in 17. Until Chrome re-enables it broadly, JPEG XL is not a practical choice for the open web.

Is AVIF worth it for images under 50 KB?

Usually not. The relative size win on small images is small in absolute terms, and the encode time is the same whether the input is big or small. For icons, thumbnails, and small UI images, WebP or PNG is fine.

How much bandwidth will I actually save?

Depends on your mix. Sites with photography-heavy content see 20–40% total bandwidth reduction moving from JPEG to AVIF. Sites with mostly UI and illustration content see less. Run a representative sample through your conversion pipeline and measure.

Do animated WebP and AVIF work?

Both formats support animation. Animated AVIF is essentially AV1 video with image-file framing. For short looping clips, both are dramatically smaller than animated GIF. For anything longer than a few seconds, use actual video (<video> with MP4 or WebM), which is always more efficient than an image format pretending to be video.

What about alpha channel support?

Both WebP and AVIF support full alpha channels, unlike JPEG. This alone is a reason to switch from PNG+JPEG hybrids to WebP/AVIF: you get transparency with the compression benefits. Test at your target quality to make sure edges stay clean.

Closing thought

Format choice is unglamorous infrastructure work, but it is one of the few performance levers that pays back immediately. Every kilobyte you do not send is a kilobyte the user's device does not decode, and the math compounds across every visit. Convert a handful of your actual images right now in the browser, look at the file sizes, look at the faces up close, and pick the pattern that fits your pipeline. The right answer is rarely "just use the new thing." It is usually "use both, with a fallback, and measure."