WebP and AVIF in WordPress

WordPress accepts WebP and AVIF uploads, but it does not convert anything for you. Upload a JPEG and you get JPEGs back in every size. Getting modern formats onto the page takes one of three routes: convert on upload, convert the existing library with a plugin, or let a CDN negotiate the format per request.

AVIF vs WebP

AVIF wins on bytes for photographs; the gap narrows for flat graphics and screenshots, where WebP-lossless often matches it. The real constraint is encoding: generating AVIF for every registered size on a shared host is slow enough to time out uploads. That is why most sites serve WebP everywhere and add AVIF only where a cloud optimizer or CDN does the encoding.

Check what your server can do

Tools → Site Health → Info → Media Handling lists the image editor (Imagick or GD) and the supported formats. If WebP or AVIF is missing there, WordPress cannot generate those files itself, and uploads of that type may be refused — the same family of errors as sorry, this file type is not permitted.

From code, the same check is:

<?php
$avif = wp_image_editor_supports( array( 'mime_type' => 'image/avif' ) );
$webp = wp_image_editor_supports( array( 'mime_type' => 'image/webp' ) );

Route 1: convert on upload, without a plugin

Since WordPress 5.8 the image_editor_output_format filter maps an input type to an output type for the generated sizes:

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

Put it in a small plugin or functions.php. The uploaded JPEG is kept on disk as the original, but since WordPress 6.7 the full size and every generated size WordPress inserts into posts become WebP. Limitations:

• it affects only new uploads — the existing library stays as it is;
• there is no fallback, so the src points straight at a .webp file;
• it depends entirely on the server's encoder.

For a new site on a good host, this is enough. For a site with years of uploads, it is not.

Route 2: a plugin converts and serves

An image optimization plugin generates .webp or .avif copies next to every original and every size, then serves them one of two ways:

• Markup rewrite — <img> becomes <picture> with <source type="image/avif"> and <source type="image/webp"> and the JPEG as fallback. Works on any host; can clash with page builders and HTML caching.
• Server rewrite — an .htaccess or nginx rule serves photo.jpg.webp when the browser's Accept header includes image/webp. Markup stays untouched. The response must vary on Accept, or a cache serves WebP to a browser that asked for JPEG. Behind Cloudflare or another CDN that ignores Vary, use <picture> markup instead — an edge cache will otherwise hand one format to every browser.

Converting a large library is the part that needs care: it is CPU-intensive locally and quota-heavy in the cloud. Imagify handles this from its own servers — it converts the existing library to WebP or AVIF in bulk and lets you choose <picture> tags or rewrite rules for delivery (on nginx the rewrite rules are added by hand), which sidesteps the missing-encoder problem on shared hosting. Selection criteria for the whole category are in choosing an image optimization plugin.

Route 3: the CDN negotiates

Some CDNs convert on the fly: the origin keeps only JPEGs and PNGs, the edge reads the Accept header and returns WebP or AVIF. Nothing changes in WordPress and there is nothing to bulk-convert. The catch is cost and lock-in — turn the feature off and you are back to JPEGs. If your CDN is in front of the site already, see Cloudflare and WordPress for how its caching interacts with this.

Disk space and quotas

Converting a library adds files rather than replacing them: every original and every generated size gets a WebP twin, and an AVIF one if you enable both. Expect the uploads folder to grow by roughly two-thirds for WebP alone, and more with AVIF on top — permanently, even though each visitor downloads less. Check disk limits on shared hosting before a bulk run, and with cloud optimizers check the quota first, since every generated size and every format copy is processed and counted.

Which route

• New site, good host → Route 1, nothing to install.
• Existing library, shared hosting → Route 2 with a cloud optimizer.
• High-traffic site already on an image CDN → Route 3.
• Never combine two of them on the same images; double conversion and two competing rewrites are the usual cause of images not showing after enabling WebP.

Common mistakes

• Deleting the originals after conversion. Social previews, RSS readers and email still need JPEG.
• Caching without Vary: Accept under server-side negotiation, so one browser's format is served to everyone.
• Converting logos and icons. An SVG should stay SVG; a tiny PNG often grows as WebP.
• Lazy-loading the LCP image after switching formats, and blaming the format for a worse LCP — see lazy loading images.

Verify

1. Open a post in a private window, DevTools → Network → Img, and add the Type column: photos should show webp or avif.
2. Request one image with curl -H "Accept: image/jpeg" and confirm you still get a JPEG.
3. Check the response headers of a converted image for Vary: Accept when the server or CDN negotiates — the method is in how to check HTTP headers.
4. Compare page weight before and after on the same URL.