If you only remember one sentence from this article, make it this one: for most WordPress sites in 2026, the format that wins is "WebP first, AVIF on top, JPEG as the floor" — and the interesting question isn't which single format to pick, but whether bolting AVIF onto a working WebP pipeline is worth the cost on your stack. Let's settle that properly.

The verdict, stated plainly

WebP wins the default slot. It is supported by every browser a real visitor uses, WordPress core has encoded and served it since version 5.8, and it cuts a typical JPEG by roughly 25–35% at quality 80 with encoding times measured in hundreds of milliseconds. That combination — universal support, mature tooling, cheap encoding — is why WebP is the safe baseline and AVIF is the upgrade, not the other way around.

AVIF wins on raw compression. Built on the AV1 video codec, it lands roughly 50% smaller than JPEG and about 25% smaller than WebP for photographic content, and it handles smooth gradients (skies, skin, bokeh) without the blocky banding that WebP can produce at aggressive quality settings. But that extra 25% arrives with strings attached, and whether those strings matter is entirely a function of where your site is hosted and what your images look like.

The real decision: does the extra 25% pay rent?

The honest framing is marginal-value. The jump from JPEG to WebP is the big, easy win — it's the difference that actually moves a page from a 2.8s LCP to under the 2.5s Core Web Vitals "good" threshold on a mid-range phone. AVIF adds a second, smaller increment on top. Ask three questions before you spend effort chasing it.

1. Is your page weight actually image-bound?

Pull up your slowest template in any waterfall tool and look at what the Largest Contentful Paint element is. If your LCP is a hero photograph and images make up the bulk of your transferred bytes, AVIF is worth pursuing — shaving another 25% off a 400 KB hero is a real, visitor-perceptible win. If your LCP is dominated by render-blocking CSS, a bloated theme, or a slow TTFB (you want server response comfortably under 600 ms), then AVIF is polishing a corner that isn't your bottleneck. Fix the bottleneck first; the format war is a rounding error next to a 1.5s server stall.

2. What kind of images are they?

AVIF's lead over WebP is widest on photographs with continuous tone and large flat-ish regions. On flat-color graphics, screenshots with sharp text, and logos, the two formats are much closer, and for line art you often want lossless WebP or even a tuned PNG instead. A photography portfolio or a travel blog benefits enormously from AVIF. A SaaS marketing site whose "images" are mostly UI screenshots and icons will see a far smaller gain — possibly not enough to justify the encoding burden below.

3. Can your host afford the encoder?

This is the question that quietly decides the whole thing, and it's where generic advice falls apart. AVIF encoding is expensive: pushing a 4-megapixel photo through the reference libaom encoder at good settings can take 5–15 seconds of CPU, versus a few hundred milliseconds for WebP. On a single-vCPU shared host, generating AVIF for every uploaded image and its resized variants will peg the CPU, slow the admin, and on some hosts trip resource limits or time out mid-conversion. So the answer to "should I use AVIF" depends on who does the encoding.

Match the approach to your hosting

Rather than ranking plugins, decide who carries the encoding cost — that choice is what actually constrains your options.

Shared or budget hosting (single vCPU, strict limits): Do not encode AVIF locally. Either skip it and run a clean WebP-only setup, or offload the work to an image CDN that converts on the fly and caches the result — Optimole and similar services convert and serve the right format per request without touching your server's CPU. Your origin keeps storing JPEGs; the CDN does the heavy lifting.
Managed WordPress (Kinsta, WP Engine, Cloudways, Rocket.net): You usually have enough CPU headroom for off-peak batch conversion, but check whether your host already runs an image-optimization or CDN layer (several bundle Imagify, Optimole-style services, or polish CDNs) before adding a second one and double-compressing. Stacking two optimizers is a common, invisible cause of mushy images.
VPS, dedicated, or your own server: You can run local AVIF encoding sanely. Throttle it — encode in the background, not synchronously on upload — so a bulk media import doesn't lock up the dashboard. This is also where a CDN-side conversion service (Cloudflare Polish in Pro/Business plans converts to AVIF/WebP automatically) frees you from managing encoders at all.

Whatever path you choose, prefer offloading conversion to a service or a background queue over synchronous on-upload encoding. The single worst configuration is "convert to AVIF locally, on the main request, on a shared host" — it's slow for editors and fragile under load.

You don't actually have to choose: serve both

The format question contains a false premise — that you pick one. The browser picks one, per visitor, if you serve a <picture> element with stacked sources:

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

A browser walks the sources top to bottom and takes the first type it understands: AVIF for current Chrome, Firefox, Edge, and Safari (AVIF landed in Safari with iOS 16 / macOS Ventura in 2022, so visitors on older iPhones quietly fall through), WebP for everything since the mid-2010s, and the JPEG <img> as the universal floor. The markup overhead is a couple hundred bytes per image — negligible against the kilobytes you save. Always keep the width and height attributes so the browser can reserve space and avoid layout shift, which protects your CLS score independent of format.

Most serious image plugins generate this markup for you once you enable both AVIF and WebP serving, so in practice "AVIF vs WebP" collapses into "switch both on and let the browser arbitrate." WordPress core helps here too: it has served WebP since 5.8 and added AVIF serving in 6.5 (2024), though core still won't auto-generate AVIF on upload — that conversion remains a plugin's or a CDN's job.

One accuracy caveat worth internalizing

That tidy "AVIF is 50% smaller than JPEG" figure assumes a good, slow encoder at sensible settings. Many WordPress tools and CDNs use faster AVIF encoders to keep conversion times reasonable, and those routinely land 30–40% smaller than JPEG instead — still excellent, but not the headline number. Don't benchmark your plugin against a blog post's best-case figure; benchmark it against your own JPEGs and trust the bytes your waterfall reports.

So, which format wins?

WebP wins as your non-negotiable baseline — it's where the largest, cheapest, most universal speed gain lives. AVIF wins as a free top-up for the browsers that support it, delivered through the <picture> element so nobody is left without an image. The only sites that should think hard before turning AVIF on are image-light pages where the gain is small, or budget hosts where local encoding would cost more in CPU and editor friction than it returns in bytes — and even those can usually adopt AVIF for free by moving conversion to a CDN. Enable WebP first, add AVIF when the encoding is somebody else's problem, and keep JPEG underneath. That's the configuration that actually wins.

WebP vs AVIF for WordPress Images: Which Format Wins