If you run a WordPress site in 2026, "WebP vs AVIF" is no longer a question of whether to leave JPEG and PNG behind — that decision was made for you years ago. The real question is which next-gen format should carry your page weight, and whether the answer is "pick one" at all. Short version: AVIF wins on raw compression, WebP wins on encode speed and bulletproof compatibility, and the best WordPress setups serve both. Here is how to decide what your site actually needs.

What each format is, in plain terms

WebP is the older of the two, built by Google and based on the VP8 video codec. It landed in WordPress core back in version 5.8 (2021), so any reasonably current install can generate and serve it without a plugin. WebP typically produces files 25–35% smaller than an equivalent-quality JPEG, supports transparency (replacing PNG), and encodes fast.

AVIF is newer and derived from the AV1 video codec. It got native WordPress core support in version 6.5 (March 2024) — you can now upload an .avif file straight to the Media Library and WordPress will generate the resized sub-sizes, exactly as it does for JPEG. AVIF's headline advantage is compression: at comparable visual quality it is commonly 20–50% smaller than WebP, with the biggest wins on photographic and gradient-heavy imagery. It also handles 10- and 12-bit color depth, HDR, and wide gamut, which WebP simply cannot.

The compatibility question is basically settled

The single most outdated claim still floating around is that "AVIF support is spotty." It isn't, not anymore. Chrome has supported it since 2020, Firefox since 2021, and Safari closed the last meaningful gap with full AVIF support in Safari 16.4 (March 2023). As of mid-2026, AVIF reaches roughly 94% of global users. The remaining few percent are people on iOS 15 and older, some locked-down corporate browsers, and a long tail of in-app webviews — which is exactly why you still want a fallback rather than serving AVIF alone.

Where the two genuinely differ for WordPress

Encode cost — the caveat nobody mentions

AVIF's better compression isn't free. It is significantly more CPU-intensive to encode than WebP — often several times slower per image. On a fast dedicated server you'll never notice. On shared hosting, that difference matters in two ways: bulk-converting an existing media library of a few thousand images can hammer your CPU allotment, and on-the-fly conversion adds latency to the first request for an uncompressed asset. WebP encodes quickly enough that this is rarely a concern. If you're on a budget shared plan and converting a large back-catalog, do it in batches or offload it to a CDN that converts at the edge.

Server dependency — the real gotcha on cheap hosts

Native AVIF in WordPress only works if your server's image library supports it. That means PHP 8.1 or newer with either GD compiled with libavif or Imagick built against libheif. Managed hosts like Kinsta, WP Engine, Cloudways, and SiteGround ship this on modern stacks. A lot of cheap shared hosting still does not. Before you commit to an AVIF-first pipeline, check Tools → Site Health → Info → Media Handling in your WordPress dashboard — it reports whether AVIF is supported. If it isn't, your "AVIF" uploads silently won't generate resized versions, and you'll need a plugin or CDN that converts off-server instead.

Tooling maturity

WebP has had years longer to mature in the plugin ecosystem, so edge cases — animated images, odd color profiles, ancient browsers — are better-trodden. AVIF tooling has caught up fast but is still occasionally where you hit a rough edge. For most static photography and graphics, both are rock solid.

The setup most sites should actually use

You don't have to crown a single winner. The HTML <picture> element (or server-side content negotiation via the browser's Accept header) lets you serve the smallest format each browser supports, in priority order: AVIF first, WebP as the fallback, original JPEG/PNG as the final safety net. Modern browsers grab the AVIF, older ones fall back to WebP, and the rare ancient client still gets a working image.

In practice you rarely hand-write that markup. A conversion plugin or CDN does it for you:

ShortPixel — converts to both WebP and AVIF, with a CDN option and generous bulk processing. A strong all-rounder.
Imagify — from the WP Rocket team, clean UI, supports AVIF, integrates neatly if you already run Rocket.
EWWW Image Optimizer — can convert and serve next-gen formats including locally, useful when you'd rather not depend on a third-party API.
Converter for Media — a popular free option that rewrites delivery to serve WebP/AVIF via <picture> or rules without touching originals.
Optimole — offloads images entirely to its own CDN and serves the optimal format per device.

If you're already behind a CDN, that's often the cleanest layer to convert at: Cloudflare (Polish/Images), Bunny Optimizer, and similar edge services convert and cache the right format per request, taking the encode load off your origin entirely. One historical note worth knowing — Jetpack's Site Accelerator (Photon) long served WebP but not AVIF, so don't assume an older image CDN does AVIF; confirm it.

Why this matters for Core Web Vitals

On most content sites the hero or featured image is the Largest Contentful Paint element. LCP needs to land under 2.5 seconds to pass Core Web Vitals, and image bytes are usually the biggest lever you have over it. Cutting a 180 KB WebP hero down to a 110 KB AVIF directly shortens how long the browser spends downloading and painting your most important pixel. The gains compound across a long, image-heavy page: trimming total image payload from, say, 1.5 MB to under 1 MB is the kind of change that moves a failing mobile LCP into the green. Pair next-gen formats with proper width/height attributes, lazy loading for below-the-fold images, and a fetchpriority="high" hint on the LCP image, and you've addressed the dominant cause of slow WordPress pages.

So which one wins?

For the payload, AVIF wins — it's smaller, it's now broadly supported, and WordPress supports it natively. Make AVIF the format your modern visitors actually download.

For the floor, WebP wins — it's the universal fallback that encodes cheaply and works everywhere, and it's still a massive upgrade over JPEG for the small slice of traffic that can't take AVIF.

Concretely:

On managed hosting with a real media budget: serve AVIF with a WebP fallback. Use ShortPixel, Imagify, or your CDN to generate both and let <picture> negotiate.
On cheap shared hosting, or if Site Health says AVIF isn't supported: stick with WebP for now (it's already in core), or convert AVIF off-server via a CDN so your origin never does the heavy encoding.
For galleries, photography portfolios, and HDR/wide-gamut work: AVIF is the clear choice — the compression and color depth advantages are most pronounced exactly there.

The honest answer to "which format wins for WordPress" is that you stopped having to choose the moment the tooling matured. Serve AVIF to the 94% who can take it, WebP to the rest, and spend the saved kilobytes on a faster LCP instead of an argument.

WebP vs AVIF: Which Format Wins for WordPress?