WebP vs AVIF in WordPress: Which Format Wins?

I converted a client's entire WooCommerce catalog (3,400 product images) from JPEG to AVIF last quarter. Total image payload across category pages dropped from 14.2 MB to 6.1 MB. PageSpeed's image audit went from 38 warnings to zero. WebP vs AVIF in WordPress is not a theoretical debate anymore. AVIF wins on file size, and as of mid 2025, every major browser supports it.

AVIF Is Smaller. Period.

AVIF files are consistently 30 to 50% smaller than WebP at equivalent visual quality. That is not a marketing number from a codec vendor. That is what I see in production across real WordPress sites. On a client's photography portfolio, AVIF files averaged 43% smaller than WebP equivalents at the same perceived quality. At scale, that difference is enormous.

WebP was a major leap over JPEG when Google released it in 2010. It delivered 25 to 35% smaller files with no visible quality loss. For over a decade, it was the best next gen format available. But AVIF, based on the AV1 video codec, uses more advanced compression techniques that WebP simply cannot match. Better color depth, better handling of gradients, better detail preservation at low file sizes.

The numbers matter because images are still the single largest contributor to page weight on most WordPress sites, a key factor in reaching a PageSpeed score of 90. The HTTP Archive reports that images account for roughly 42% of total page weight across the web. When you can cut that 42% nearly in half by switching formats, the performance impact is immediate and measurable.

The Browser Support Question Is Settled

Browser support was the legitimate reason to stick with WebP over AVIF 18 months ago. That argument is over. Chrome, Firefox, Safari, Edge, and Opera all support AVIF. iOS Safari added support in version 16.4 (March 2023). As of mid 2025, global AVIF support sits above 95% of web traffic according to Can I Use data.

The remaining sliver is older browsers and some niche platforms. You still need a fallback, but the fallback is WebP (which has near universal support), not the original JPEG. A properly configured <picture> element handles this automatically: serve AVIF to browsers that support it, WebP to the rest, and original format as the final fallback. The browser picks the best format it can handle. Zero user intervention required.

I hear people say they will wait for "full" support. Full support is never 100%. IE11 never supported WebP either, and that did not stop anyone from adopting it. The practical threshold for adopting a new image format is around 90%, and AVIF passed that over a year ago.

What Most Comparison Posts Miss: The WordPress Angle

Most articles comparing WebP and AVIF list file size benchmarks and call it a day. They ignore the WordPress specific complications that actually determine whether you can use these formats in production.

WordPress core added WebP upload support in version 5.8 (July 2021). AVIF upload support landed in WordPress 6.5 (April 2024), but only when the server has the right libraries installed. That second part is where things get messy. Your hosting environment needs PHP compiled with either libavif support through GD, or Imagick compiled with AVIF support. Many shared hosts still do not have this.

I learned this the hard way on a client migration last year. Everything tested perfectly on a staging server running PHP 8.2 with an up to date GD library. Pushed to production on their shared host, and AVIF uploads silently failed. WordPress did not throw an error. It just did not generate the AVIF thumbnails. The original JPEGs loaded fine, so nobody noticed for two weeks that the site was serving unoptimized images on every product page.

Then there is the theme problem. Not every WordPress theme uses <picture> elements for image output. Many themes, especially older ones, use simple <img> tags and rely on WordPress to generate the right srcset. If your theme does not output proper <picture> markup with format fallbacks, you are either serving AVIF to everyone (breaking it for the 5% who cannot decode it) or not serving it at all.

The Encoding Cost Nobody Talks About

AVIF's compression advantage comes at a cost: encoding is significantly slower than WebP. On a modern dedicated server, encoding a single high resolution image to AVIF can take 2 to 5 seconds. WebP encodes the same image in under a second. For a site with a few dozen images, this is irrelevant. For a WooCommerce store with thousands of product photos, the encoding time adds up fast.

On shared hosting, the problem is worse. AVIF encoding is CPU intensive, and shared hosts throttle CPU usage aggressively. I have seen bulk AVIF conversion jobs time out on shared hosting because the server kills the process for exceeding CPU limits. One client's host returned 500 errors after trying to encode their 200th image in a batch.

This is the tradeoff most comparison articles gloss over. AVIF produces smaller files, but generating those files requires meaningful compute resources. If your WordPress host cannot handle the encoding, it does not matter how good the format is. Your options become: encode locally and upload (tedious at scale), use an external service (adds a dependency and often a recurring cost), or use a plugin that handles encoding intelligently with queuing and resource limits.

WebP encoding is cheap and fast by comparison. If you are on budget hosting and need next gen images today with zero encoding headaches, WebP is the pragmatic choice. If your server can handle AVIF encoding (VPS, dedicated, or managed WordPress hosting with modern PHP), AVIF is the better format in every other dimension.

Fallback Strategy Matters More Than Format Choice

The format debate misses the more important question: how does your WordPress site handle fallbacks? A site serving AVIF with proper <picture> element fallbacks will outperform a site serving WebP with no fallback strategy at all. The implementation matters more than the format.

The correct approach is a cascading <picture> element. AVIF as the first source, WebP as the second, and the original JPEG or PNG as the default <img> tag. The browser evaluates sources top to bottom and uses the first format it supports. This is a solved problem in HTML. The challenge is getting WordPress to output this markup automatically for every image across your entire site.

Most image optimization plugins handle WebP conversion and output. Fewer handle AVIF. Even fewer handle the <picture> element rewriting needed to serve the right format to each browser. Some plugins use server side content negotiation instead, rewriting image URLs based on the browser's Accept header. That works but requires specific server configuration and can conflict with CDN caching.

After working with next gen image formats across dozens of client sites, the pattern I see is that people focus on which format is "best" and skip the implementation details that actually determine whether it works. A poorly implemented AVIF setup (no fallbacks, broken on Safari, encoding failures on shared hosting) is worse than a well implemented WebP setup that works reliably everywhere.

When WebP Still Makes Sense

AVIF is the better format on paper. But "better format" and "better choice for your site" are not always the same thing. There are real scenarios where WebP is the more practical option.

If your hosting does not support AVIF encoding and you cannot switch hosts, WebP gives you 25 to 35% savings over JPEG with near zero encoding overhead. That is still a massive improvement. A site going from JPEG to WebP will see noticeable performance gains even if AVIF would theoretically save more.

If you need transparency with small file sizes, WebP handles alpha channels well and encodes faster than AVIF for transparent images. Icon sets and UI elements with transparency are a reasonable WebP use case. AVIF supports transparency too, but the encoding time penalty makes it less practical for large batches of small transparent images.

If your audience skews toward older devices or enterprise environments with locked down browsers, WebP's broader legacy support (going back to Chrome 32 in 2014) reduces your fallback surface area. This is an edge case for most sites, but I have seen it matter on B2B sites where visitors are stuck on corporate managed browsers.

The Real Answer: Use Both

The WebP vs AVIF debate frames this as a choice. It is not. The correct approach for WordPress in 2026 is to generate both formats and let the browser pick. AVIF for the 95%+ of visitors with modern browsers. WebP for the rest. Original format as the ultimate fallback.

This is exactly how the <picture> element was designed to work. It is not wasteful to generate multiple formats because the visitor only downloads one. The extra storage for three versions of each image is negligible compared to the bandwidth savings from serving the optimal format to every visitor.

The storage math works out clearly. Say you have a 500 KB JPEG. The WebP version is about 350 KB. The AVIF version is about 225 KB. You are storing an extra 575 KB on disk, but every visitor who gets the AVIF version saves 275 KB of bandwidth on that single image. Across a site with hundreds of images and thousands of visitors, the bandwidth savings dwarf the storage cost.

The tricky part is not the format decision. It is the implementation: generating both formats reliably, outputting the right markup, handling fallbacks, and not killing your server during bulk conversion. That is the kind of problem a dedicated performance plugin handles well, and the kind of problem that is tedious and error prone to solve manually across an entire WordPress site.

Frequently Asked Questions

Is AVIF better than WebP for WordPress?

AVIF produces files 30 to 50% smaller than WebP at the same visual quality. Every major browser now supports AVIF, making it the superior format for most WordPress sites. The main consideration is whether your hosting environment supports AVIF encoding, which requires modern PHP libraries that some shared hosts lack.

Does WordPress support AVIF images?

WordPress added AVIF upload support in version 6.5 (April 2024). However, your server needs PHP compiled with AVIF capable libraries (GD with libavif or Imagick with AVIF support). Many managed WordPress hosts now include this, but budget shared hosting often does not. Check with your host before assuming support is available.

Should I convert all my images to AVIF?

Generating AVIF versions of your images is worthwhile, but you should keep WebP and original formats as fallbacks. The best approach uses the HTML picture element to serve AVIF to supported browsers and WebP to the rest. Never serve only AVIF without a fallback strategy, as a small percentage of visitors still cannot decode it.

Does AVIF affect WordPress page speed?

AVIF significantly improves page speed because smaller image files mean faster downloads. On image heavy pages, switching from JPEG to AVIF can reduce total page weight by 50% or more. The improvement is most dramatic on mobile connections where bandwidth is limited and images are the largest contributor to load time.

Can I use both WebP and AVIF on WordPress?

Yes, and you should. The picture element lets you specify multiple image formats in priority order. The browser downloads only the first format it supports. This gives every visitor the smallest possible file without breaking compatibility. A performance plugin can automate the conversion and markup rewriting across your entire site.