AVIF vs WebP in late 2022: when the newer format actually wins

AVIF generally produces smaller file sizes than WebP at equivalent visual quality, sometimes by a meaningful margin, especially on photographic images with lots of fine detail. That doesn't automatically make it the right default choice for every image on every site, and the actual decision depends on browser support, encoding time, and where in the page the image sits.

By late 2022, AVIF support across major browsers has become solid, but not universal, and older or less common browsers may still fall back to nothing at all without a proper fallback chain. We always serve AVIF with a WebP and JPEG fallback via the picture element or content negotiation, rather than serving AVIF alone and assuming every visitor's browser supports it.

AVIF encoding is meaningfully slower than WebP encoding, which matters more than people expect for sites with large image libraries or frequent content updates, since build or deployment pipelines that re-encode images can see noticeably longer build times. For a site with a handful of hero images, this is a non-issue. For an eCommerce catalog with thousands of product photos, it's worth testing before committing.

For simpler images, especially graphics, logos, and screenshots with large flat color areas rather than photographic detail, the file size gap between AVIF and WebP narrows considerably, sometimes to the point where WebP's faster, simpler encoding pipeline makes it the more practical choice for that image type specifically.

For hero images and other large photographic assets above the fold, where every kilobyte directly affects LCP, we default to AVIF with fallbacks. For smaller supporting images and graphics throughout the rest of the page, WebP alone is usually sufficient and simpler to manage. This isn't a universal rule, it's a starting point we adjust per project based on actual image content.

Format choice matters less than most people assume compared to simply serving an image at the size it's actually displayed at. A perfectly encoded AVIF file that's still four times larger than the display size wastes more bandwidth than a properly sized JPEG. Get responsive sizing right first; format optimization is the second, smaller lever, not the first one to pull.

Manually deciding AVIF versus WebP for every image on a large site doesn't scale, and most teams don't have the bandwidth to make that call image by image. We prefer image pipelines, whether a CDN's built-in transformation service or a build-time tool, that automatically generate multiple formats from a single source image and serve the best one a given browser supports, with sizing handled the same way. This removes the decision from individual content editors entirely and applies a consistent policy across the whole site without anyone needing to remember the rule.

The upfront setup cost of a proper image pipeline is higher than manually exporting a few hero images by hand, but it pays off as soon as a site has more than a handful of images that change regularly, since manual optimization tends to quietly stop happening once the person who set it up moves to a different project or leaves the team.

Rather than picking a format policy from a general rule, we run a small side-by-side test on a representative sample of the actual site's images: a hero photo, a product shot, a graphic with text, a logo. Comparing real file sizes and visual quality across AVIF, WebP, and a well-optimized JPEG baseline for that specific image set tells us more than any general benchmark, since compression performance varies meaningfully by image content, and a rule that holds for one client's photography style doesn't always hold for another's.

This test takes under an hour and it's the difference between a format decision based on the specific images a site actually uses versus a generic best practice that might not apply to this particular case. We've had clients where WebP alone was nearly indistinguishable from AVIF in file size for their specific image style, which made the added encoding complexity of AVIF not worth adopting for that project.

A meaningful share of the sites we audit haven't adopted either newer format yet, and are still serving unoptimized JPEG and PNG files directly from a CMS upload with no compression or resizing pipeline at all. For these sites, the AVIF versus WebP debate is genuinely secondary. Simply adding basic compression and responsive sizing to existing JPEGs usually recovers more performance than jumping straight to a next-generation format on top of an otherwise unoptimized pipeline.

We sequence this work accordingly: fix sizing and basic compression first, since it's a bigger, cheaper win, and treat format modernization as the next step once that foundation is in place. Recommending AVIF to a client whose images are still being served at four times their display size, uncompressed, is solving the smaller problem while leaving the larger one untouched.

Open your site's largest images in a browser's network tab and compare the file's actual dimensions against how large it displays on the page. If the file is meaningfully larger than its display size, that's the first fix regardless of format. Then check whether your CDN or hosting platform already offers automatic format negotiation, many do, as a built-in feature that might already be available and simply not turned on.

Image format standards keep moving, and whatever's true about AVIF versus WebP today will likely shift again as browser support and encoder tooling mature further. We revisit this comparison periodically rather than treating any single format recommendation as permanent, since a format that made sense to skip two years ago for encoding-speed reasons may be worth reconsidering once tooling catches up.