WebP vs AVIF for WordPress images in 2026

Almost every “WebP vs AVIF” article you will find is written by a company that sells an image-optimization plugin, and they all reach the same conclusion: use their plugin. The technical facts they quote are correct. AVIF files are usually 20 to 50 percent smaller than WebP at the same visual quality. What those articles skip is the part that actually decides it on a real WordPress site: what the conversion costs you in CPU, storage, and headaches. We run WordPress performance work for clients on everything from $5 VPS boxes to managed stacks, and the honest answer is that AVIF is the better format and WebP is still the better default for most sites. Here is why those two things are not a contradiction.

What actually differs between the two formats

Both are modern formats that beat JPEG and PNG badly. WebP came out of Google in 2010 and has been the safe web format for years. AVIF is newer, built on the AV1 video codec, and compresses harder, especially on photos with lots of detail and gradients. On a typical hero image we see AVIF land 30 to 40 percent smaller than the WebP version at a quality level nobody can tell apart on a screen.

WebP has one thing AVIF still cannot match: it is faster to create. AVIF encoding is expensive. Squeezing that extra compression out means the encoder does a lot more work, and on a busy shared host that cost shows up as CPU time and slow media uploads. That single difference drives most of the practical decision, and none of the vendor comparisons mention it.

Browser support is no longer the argument

For years the case against AVIF was browser support, and that case is basically over. By 2026 AVIF works in current Chrome, Firefox, Safari, and Edge, which covers well over 90 percent of real traffic. The stragglers are old Safari versions and a few embedded browsers. So the “WebP is safer” reasoning that dominated 2022-era comparisons does not really hold anymore on the compatibility front.

It holds for a different reason now, and that reason is operational, not about which browser can open the file. Any sane setup serves the modern format with an automatic fallback anyway, so a visitor on an ancient browser just gets the JPEG. Nobody sees a broken image either way.

WordPress handles both, but not the way people think

Since version 6.5, WordPress supports AVIF natively. You can upload an AVIF file and it works, the same way WebP has worked since 6.1. What WordPress does not do on its own is convert your existing JPEGs and PNGs to either format. Core added support for the file types; it did not add a conversion pipeline. That is the gap every optimization plugin fills, and it is the real reason you end up installing one.

When a plugin converts your library, it does not replace the originals. It generates new WebP or AVIF copies and serves those, keeping the JPEG as the fallback. Turn on both formats and you now store three versions of every image: the original, the WebP, and the AVIF. On a media library with 8,000 images, that is not a rounding error. We have seen a client’s uploads folder triple in size after someone enabled “convert everything to AVIF and WebP” without thinking about disk.

The cost nobody puts in the comparison table

Here is the trade the vendor blogs leave out. Regenerating a large media library to AVIF is one of the heaviest jobs you can hand a cheap server. We watched a bulk AVIF conversion peg a 2-core VPS at full CPU for most of an afternoon and slow the live site while it ran. WebP conversion on the same library finished in a fraction of the time because the encoder is lighter.

So the size win has a price, and where you land depends on the box:

• Big media library on cheap shared hosting: WebP. The AVIF encode cost is not worth the extra few percent, and you may hit CPU limits mid-conversion.
• Photography, portfolio, or e-commerce site where image weight is the whole game: AVIF, but convert in off-peak batches and expect the storage to grow.
• Managed host or your own VPS with headroom: AVIF for new uploads, and convert the back catalogue over a few nights rather than in one run.

What we actually set up for clients

Our default on a normal business WordPress site is WebP for the whole library plus AVIF only on the images that matter for Core Web Vitals, mainly the hero and the above-the-fold shots that count toward Largest Contentful Paint. That gets almost the entire speed benefit where Google is measuring, without paying the AVIF encode tax on 8,000 blog thumbnails nobody scrolls to.

We pair that with real caching and a CDN so the converted images are served from the edge, not re-encoded on every request. The format is only one lever. A site still shipping render-blocking scripts and no page cache will not be saved by a smaller image, which is why image format is one line item in our broader WordPress speed work rather than the headline fix. If you are choosing a cache layer alongside this, we compared the two we reach for most in LiteSpeed Cache versus WP Rocket.

So which one

If someone forces a one-word answer: AVIF, because the compression is genuinely better and browser support caught up. But the useful answer for a real WordPress site is that WebP everywhere plus AVIF on your hero images gives you 95 percent of the result for a fraction of the server cost, and that is what we ship unless a client’s whole business is images. Do not let a plugin talk you into re-encoding an entire library to AVIF on a $5 box just because a comparison table said AVIF is smaller. Smaller is not free.

If you would rather not test encoders and watch CPU graphs, image work is part of our WordPress performance pack, and we tune the format mix to your actual hosting and traffic. Ongoing tuning and the occasional “why did my site get slow again” call live in our WordPress support plans.