To convert images to WebP in WordPress (or AVIF), you can rely on native support (WebP since WordPress 5.8, AVIF since 6.5) when your server’s image library supports the format, use an optimisation plugin that converts new and existing uploads with fallbacks, or let a CDN convert images on the fly. Keep originals and check the result on real pages.
Images are usually the heaviest part of a page and often the LCP element, so this is one of the most effective speed fixes.
WebP vs AVIF: which should I use?
Use both when you can. AVIF typically gives smaller files at similar quality, particularly for photographs, but takes longer to encode and some older browsers lack support. WebP is a dependable middle ground with very broad support. A good setup serves AVIF to browsers that accept it, WebP to others, and JPEG or PNG as the last fallback.
Step 1: check what your server supports
WordPress uses Imagick or GD to create resized images. Whether it can produce WebP or AVIF depends on how those libraries were compiled on your host.
Check in Tools → Site Health → Info → Media Handling, or with WP-CLI:
wp eval 'var_dump( wp_image_editor_supports( array( "mime_type" => "image/avif" ) ) );'
wp eval 'var_dump( wp_image_editor_supports( array( "mime_type" => "image/webp" ) ) );'
If AVIF returns false, your host’s library lacks it; use a plugin or CDN that converts elsewhere, or ask the host.
Step 2: choose your approach
Option A: native WordPress output format
Since WordPress 5.8, the image_editor_output_format filter lets you tell WordPress to generate sub-sizes in a different format:
add_filter( 'image_editor_output_format', function ( $formats ) {
$formats['image/jpeg'] = 'image/webp';
return $formats;
} );
This affects new uploads’ generated sizes. It is simple, but you manage fallbacks and existing images yourself.
Option B: an optimisation plugin
Most popular image optimisation and caching plugins can convert uploads to WebP and AVIF, bulk-process the existing library, and rewrite the HTML to <picture> elements or use server rules to serve the best format. This is the most practical route for most sites.
What to look for:
- Converts both new uploads and the existing library.
- Keeps originals.
- Provides fallbacks via
<picture>orAcceptheader rules. - Lets you set quality per format.
- Excludes specific images when needed (logos, SVGs).
Option C: CDN conversion
Image CDNs and some CDN features convert and resize at the edge based on the browser’s Accept header. No load on your server, but check costs and make sure the cache varies correctly by format.
Step 3: fallbacks with picture
When serving through HTML:
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" width="1200" height="800" alt="Handmade leather bag">
</picture>
The browser takes the first type it supports. Width, height and alt stay on the <img>.
Step 4: don’t forget dimensions
Format conversion of a 4000 px image still wastes data on a phone. Check:
- Upload sizes: resize huge originals before or at upload. WordPress scales very large images down to a maximum of 2560 px by default (the “big image” threshold).
srcsetandsizesare present so the browser picks a suitable width.- Theme image sizes match how images are actually displayed.
- Width and height attributes exist to prevent layout shift (CLS).
Step 5: bulk convert existing images
On a large media library, bulk conversion can strain a slow server. My approach:
- Back up
wp-content/uploads. - Run conversion in small batches, outside peak hours.
- Regenerate missing thumbnails only where needed:
wp media regenerate --only-missing --yes
- Spot-check pages for broken or blurry images.
More commands are in my WP-CLI guide.
Quality settings
There is no universal number. Start with moderate quality, compare visually at real display size, and adjust. Product photos with fine texture may need more; decorative backgrounds can go lower. Logos and illustrations with flat colours are often better as SVG or lossless WebP.
Alt text and SEO
Changing format should not change meaning. Keep descriptive alt text, keep filenames readable (blue-leather-bag.jpg, not IMG_0042.jpg), and make sure image sitemaps or SEO plugins point to working URLs.
Checklist
- Server support for WebP/AVIF checked
- Approach chosen: native, plugin or CDN
- Originals kept
- Fallbacks working in browsers without AVIF
- Dimensions and srcset correct
- Existing library converted in batches
- LCP image verified in the new format
- Visual quality checked on real devices
Common mistakes
- Converting PNG logos to lossy formats and getting blurry edges.
- Serving AVIF without a fallback.
- A CDN cache that does not vary by format, serving AVIF to a browser that cannot show it.
- Bulk converting on a shared host during business hours and slowing the site.
Need your media library optimised safely? Contact me. Next in this series: self-hosting Google Fonts.
Frequently asked questions
Is AVIF better than WebP?
AVIF often produces smaller files at similar visual quality, especially for photos, but encoding is slower. WebP encodes faster and is very widely supported. Many sites serve AVIF with a WebP or JPEG fallback.
Does WordPress support AVIF?
Yes. WordPress 6.5 added AVIF support for uploads and image sizes, as long as the server's image library (Imagick or GD) supports AVIF.
Will converting images hurt SEO?
No, if image URLs keep working, alt text stays, and the images still load. Serving modern formats usually helps performance.
Should I delete the original JPEGs?
Keep originals as a fallback and for future re-encoding. Storage is cheaper than a lost source image.
