AVIF vs WebP for WordPress Product and Hero Images

Serve WebP as the baseline and AVIF as an upgrade on large photographic images. On our test set AVIF ran 25-47% smaller than WebP above 1000px wide, but it encodes 10-50x slower and often gets bigger than WebP under 300px. Content negotiation at the CDN gives you both without touching theme code.

What is AVIF, and how is it different from WebP?

AVIF is a still-image container built on the AV1 video codec, standardized by the Alliance for Open Media. WebP is built on VP8 (lossy) and VP8L (lossless), the codec generation before AV1. Both are royalty-free, both do lossy and lossless, both support alpha and animation. AVIF just has a better compression engine behind it.

The practical differences that matter when you are picking a format for a WordPress site:

AVIF supports 10-bit and 12-bit color depth and wide gamut. WebP is 8-bit only. If you run a photography site or a product catalog with brand-critical color, that matters. For most sites it does not.

AVIF handles smooth gradients and low-detail areas far better. Sky, studio backdrops, blurred bokeh, soft shadows on a white product background: this is where the 40% savings show up. WebP tends to band in those regions unless you push quality up, which erases its size advantage.

AVIF is worse at small images. The container carries more metadata overhead, and the codec's block structure does not pay off when there are only a few thousand pixels. Below roughly 200x200, AVIF frequently produces a larger file than WebP at the same quality.

Netflix published a detailed AVIF evaluation on its technology blog showing BD-rate improvements over WebP across their test corpus (2020), and every independent test since has landed in the same general range. The savings are real. The question is what they cost you to produce.

Is AVIF browser support good enough in 2026?

It is, for delivery with a fallback. AVIF became Baseline newly available in January 2024 when Edge 121 shipped support, and Can I Use currently puts global support above 94%. The remaining gap is old Safari, old Android WebView, and a long tail of embedded browsers.

Here is the support timeline that matters for your fallback decision:

The Safari 16.4 cutoff is the one that catches people. Anyone on an iPhone stuck at iOS 15 (models that stopped getting updates, or users who never tap the button) gets no AVIF. Check your own analytics before assuming that group is zero. On B2B sites we manage it is usually under 1%. On sites with older or lower-income audiences we have seen it run 3-4%.

Adoption on the web is still thin. The HTTP Archive Web Almanac media chapter found AVIF on well under 1% of pages surveyed while WebP sat around 10% (2022), and later runs show AVIF growing but still in low single digits. That tells you nothing about whether AVIF works, only that tooling has been slow. WordPress core only added AVIF support in 6.5, released March 2024.

How much smaller is AVIF than WebP on real WordPress images?

On photographic content above 1000px, expect 25-47% smaller. On screenshots, flat illustration, and anything under 400px, expect single digits or a loss. These are measurements from a test set we ran across client media libraries, encoded with cwebp -q 80 and avifenc -q 55 --speed 6, checked for visual parity at 1x and 2x.

Two things to take from that table. First, the LCP image on a product page or a homepage hero is exactly where AVIF pays. That is one request, usually the largest one, and cutting 100 KB off it moves Largest Contentful Paint on a slow connection. Our breakdown of how WordPress site speed connects to conversion rate goes further into that, but the LCP image is where most of the available win sits.

Second, converting your entire media library to AVIF is mostly wasted CPU. The 300px thumbnails in a shop grid are already small, and AVIF makes some of them worse. Generate AVIF for the sizes that appear above the fold at real dimensions, and leave the rest as WebP.

One quality-mapping note: AVIF quality numbers are not comparable to WebP quality numbers. In libavif's newer -q 0..100 scale, somewhere around 50-60 tends to match WebP q75-80 perceptually on photos. Use -q 63 and 4:4:4 subsampling for anything with text or hard edges; --yuv 420 on a screenshot will smear the type.

What does AVIF encoding cost in server time?

A lot more than WebP. AV1 intra-frame encoding is heavy, and the speed setting in libavif trades size for time on a steep curve. These are wall-clock encode times on a 4 vCPU cloud instance, single image, single thread disabled from oversubscribing:

Now multiply by your registered image sizes. A typical WooCommerce install has six to nine sub-sizes once you count theme additions. If you generate both WebP and AVIF for all of them at speed 6, a single 4000px camera upload turns into 15-20 seconds of encoding inside a PHP request that also has to finish before the media uploader stops spinning. On shared hosting with max_execution_time at 30 you will hit the wall, and the symptom looks like a broken uploader rather than a timeout.

Three ways out, in order of how well they hold up:

1. Convert at the edge. The CDN encodes once on first request, caches the result, and serves from cache after that. Your origin never runs an AV1 encoder.
2. Convert offline. Batch the library with avifenc -s 4 over SSH or WP-CLI, queue new uploads through Action Scheduler instead of doing the work inline.
3. Convert inline at speed 8 or 9. Fast enough to survive a PHP request, but you give back roughly 10-15% of the size advantage.

If your host cannot run any of the three, that is a hosting constraint rather than an image problem, and it belongs on the list of signs it is time to switch WordPress hosts.

How to serve AVIF and WebP from the same WordPress site

Three mechanisms work in 2026. Pick based on where you want the CPU cost to land.

The image_editor_output_format filter. Core's built-in route. It swaps the output format when WordPress generates sub-sizes, so uploads produce one modern format instead of JPEG:

add_filter( 'image_editor_output_format', function ( $formats ) {
	$formats['image/jpeg'] = 'image/avif';
	$formats['image/png']  = 'image/avif';
	return $formats;
} );

This produces a single format with no fallback. Use it only if you have checked your analytics and accepted the Safari 15 gap. Verify your server can encode first:

php -r 'var_dump(function_exists("imageavif"));'
convert -list format | grep -i avif

imageavif() arrived in PHP 8.1, but only works if GD was compiled against libavif. ImageMagick needs a libheif delegate. Plenty of hosts ship neither, which is another reason to check what PHP version and extensions your host runs before planning around AVIF.

A <picture> element via plugin. The Performance Lab "Modern Image Formats" plugin generates additional formats and can output a picture element with ordered sources. This is the correct HTML answer: the browser picks, no server-side sniffing, caches behave. The cost is that page builders, lazy-load scripts, and anything that filters the_content sometimes fight the markup rewrite. Test on staging.

Accept-header negotiation at the CDN. The browser sends Accept: image/avif,image/webp,*/*. The edge picks the best format it can serve, varies the cache on that header, and your HTML keeps a plain <img src="photo.jpg">. Cloudflare Polish, Bunny Optimizer, Fastly Image Optimizer, Cloudinary, and imgix all do this. It is the approach we run on client sites because it survives theme changes and it keeps encoding off the origin entirely. Our WordPress CDN setup guide covers the cache-key and Vary configuration, and if you are putting images on a separate hostname, get the certificate right first using the WordPress SSL and HTTPS setup guide.

Whichever you pick, keep the original JPEG or PNG on disk. You will want it the next time a codec generation lands. For the mechanics of bulk conversion, WP-CLI commands, and plugin comparisons, see our WordPress WebP conversion guide. Offloading the derivatives to object storage is covered in media offloading to an external server or CDN.

When WebP is still the right default

WebP stays the safe baseline for most WordPress sites, and there are cases where adding AVIF returns close to nothing.

Small images do not benefit. Avatars, icons, category thumbnails, anything under about 400px on its longest side: encode those as WebP and stop. You spend CPU and get bytes back in the wrong direction.

Text-heavy screenshots compress poorly in AVIF at 4:2:0, and at 4:4:4 the size advantage over WebP mostly disappears. Documentation sites and SaaS marketing pages full of UI captures see 5-10% wins that are not worth the pipeline complexity.

Decode time is a real consideration on cheap Android hardware. AVIF decoding is more CPU-intensive than JPEG or WebP, and on a low-end phone a large AVIF can eat part of the transfer savings during render. If your LCP element is a 3000px hero and a meaningful share of your traffic is budget Android, measure LCP both ways in field data rather than trusting the byte count.

And if your images are already served badly, format is the wrong lever. Serving a 2400px image into a 600px slot, shipping no srcset, or loading twelve above-the-fold images all at once will cost you more than any codec saves. Our list of proven WordPress speed techniques puts sizing and lazy-loading ahead of format for a reason.

Which format to serve, by site type

For a large catalog, the sequencing that has worked for us: audit and clear dead files first with a media library cleanup, switch generation to WebP, then turn on AVIF at the CDN for the two or three sizes that render above the fold. Measure LCP in field data before and after. If the delta is under 100ms, you have found your ceiling and should spend the next hour on database queries or TTFB instead.

We handle conversion, negotiation, and edge caching as part of the platform rather than as a plugin you maintain; the details of what runs on each node are on our hosting spec sheet and technology stack page, and plans start at $89/mo per site on our pricing page.

Frequently Asked Questions

Does WordPress support AVIF natively?

Since WordPress 6.5 (March 2024) you can upload AVIF files and WordPress will generate AVIF sub-sizes, provided your server's GD or ImageMagick build supports the format. What core does not do is emit a <picture> element with fallbacks, so serving AVIF to modern browsers and WebP to everyone else still requires a plugin or CDN negotiation.

Should I convert my entire media library to AVIF?

No. The savings concentrate in large photographic images, so converting thumbnails and icons burns CPU for little or negative return. Convert the sizes that render above the fold at 800px or wider, keep WebP for everything else, and always retain the original JPEG or PNG so you can re-encode later.

Is AVIF better than WebP for SEO?

Neither format is a ranking factor on its own. What matters is the effect on Largest Contentful Paint, which is part of Core Web Vitals. If AVIF cuts 120 KB off your LCP image and the page renders faster on a slow connection, that helps. If it saves 3 KB on a thumbnail, it does nothing.

What quality setting should I use for AVIF?

Around -q 55 in libavif's 0-100 scale is a reasonable starting point for photographs and maps roughly to WebP q80 in perceived quality. Push to -q 63 with 4:4:4 chroma subsampling for images containing text, logos, or hard edges, since 4:2:0 will visibly soften them.

Will AVIF break for iPhone users?

Only for devices still on iOS 15 or older, since Safari added AVIF in version 16.4 (March 2023). Check the iOS version breakdown in your own analytics before deciding. As long as you serve AVIF through a <picture> element or Accept-header negotiation, older Safari receives WebP or JPEG automatically.

Marcus Webb

DevOps & Security Lead

12+ years DevOps, Linux & cloud infrastructure certified

Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.

LinkedIn