You installed an image plugin, ticked “create WebP versions”, watched a progress bar run through the media library, and then ran another speed test. It still says “serve images in next-gen formats”. Or the test is happy, but you right-click a photo on your site and the address still ends in .jpg. Did it work or not?
When you convert images to WebP in WordPress, there are really two jobs. Making the WebP files is the easy one. Getting them delivered to visitors, with a sensible fallback and without breaking your cache, is where most setups go quietly wrong. This post walks through both, and how to prove the result.
Whether WebP or AVIF is the right format for your images is a separate question, answered in our comparison of WebP, AVIF and JPEG. Here we assume you have decided on WebP.
Three ways to convert images to WebP in WordPress
A plugin that converts on your own server
The plugin uses the image library your host has installed, usually Imagick or GD, to create a WebP copy of each image and its resized versions. EWWW Image Optimizer and Converter for Media are common examples. Nothing leaves your server, which some owners prefer, but it uses your hosting resources. On a small shared plan, converting thousands of images can be slow and may need to run in batches.
It also depends on your server’s image library actually supporting WebP. Most current hosting does. If the plugin reports that WebP is not available, that is a question for your host, not something you can fix from the dashboard.
A plugin that converts on the provider’s servers
ShortPixel, Imagify and similar services send each image to their own servers, compress and convert it there, and save the results back to your uploads folder. This takes the load off your hosting and usually handles very large libraries more comfortably. How each service meters its usage varies, so read its current terms against the size of your library before starting a bulk run.
A CDN or image service that converts on the fly
Some CDNs and image services leave your files alone and create WebP versions at the edge when a browser asks for them. Your uploads folder does not change at all. This is tidy, but it ties your images to that service, and you need to understand how it caches different versions. If you use Cloudflare, our post on how Cloudflare caches a WordPress site is worth reading before you switch on any image feature.
There is also a newer route inside WordPress itself. WordPress accepts WebP uploads, and the WordPress Performance Team’s Modern Image Formats plugin can generate WebP or AVIF versions of new uploads and use them in your content. It is a light option for new images, though it is less suited to converting an old library in bulk.
How the WebP file actually reaches the visitor
This is the part that explains most “it did not work” moments. Once WebP files exist, the plugin has to make browsers receive them instead of the original. There are three methods, and plugins often let you choose.
| Method | How it works | Watch out for |
|---|---|---|
| Picture element | The plugin rewrites your page HTML, wrapping each image in a picture tag that lists the WebP version first and the original as fallback. The browser picks. | Can affect themes or scripts that expect a plain img tag. Does not cover images set as CSS backgrounds. |
| Server rewrite | The page still asks for photo.jpg. The server checks whether the browser accepts WebP and quietly sends the WebP copy instead. | Needs rules in .htaccess (Apache, LiteSpeed) or the server configuration (Nginx). Caches and CDNs must store both versions separately. |
| URL replacement | Image addresses in the HTML are changed to point to the WebP file or a CDN address. | Old browsers or tools that cannot read WebP get nothing unless a fallback is built in. |
The server rewrite method is the reason you can see .jpg in the address bar while the browser is actually receiving WebP. The file name stays the same; the content changes. So the address bar is not a reliable test. The checks further down are.
Which method to pick
- On Apache or LiteSpeed hosting without a CDN, the rewrite method is usually clean and leaves your HTML untouched.
- On Nginx hosting, the rewrite rules have to be added to the server configuration. If you cannot do that or your host will not, use the picture method.
- Behind a CDN, the picture method is often safest, because the CDN simply caches two different files at two different addresses. A rewrite relies on the CDN respecting the browser’s Accept header, which not every setup does.
Step by step with a plugin
- Take a backup of the uploads folder and the database. Our guide to backing up a WordPress website covers how. Bulk jobs write a lot of files.
- Remove any other image optimisation plugin, or at least turn off its WebP and compression features. Two plugins doing the same job is the most common cause of broken or doubled images.
- Install one plugin and set compression first. Choose a quality level, then turn on WebP creation. Leave “replace originals” or “delete originals” off.
- Choose the delivery method using the table above. If the plugin offers a test or status check for the rewrite rules, run it.
- Convert one test image and check it on the front end before running the bulk job.
- Run the bulk conversion at a quiet time. On shared hosting, a local conversion of a large library can slow the site while it runs.
- Clear every cache: the page cache plugin, any host cache and the CDN. Otherwise visitors keep receiving pages that point at the old files.
- Turn on automatic conversion for new uploads so the problem does not come back.
Keep the originals
Most good plugins store WebP copies alongside the originals or in a separate folder, and leave your JPEG and PNG files in place. Keep it that way. Originals are your fallback for browsers or tools that do not accept WebP, the source for any future re-conversion at a different quality, and your way back if you ever remove the plugin.
The extra disk space is real, so check your hosting storage before converting a big library. If storage is tight, clearing out unused media first is a better saving than deleting originals.
Checking that WebP is really being served
A plugin settings page that says it will serve WebP images only tells you what it intends. The browser tells you what actually happened. Do this on a few different pages: the home page, a blog post, a product page if you have a shop.
- Open the page in Chrome in a private window so you are logged out, which matters because some caches behave differently for logged-in users.
- Press F12, open the Network tab, tick “Disable cache” and filter by Img. Reload.
- Look at the Type column. It should say webp for your photos, even if the file name ends in .jpg.
- Click one image and check the Response Headers. Content-Type should be image/webp. With the rewrite method, you should also see a Vary header that includes Accept.
- Check what is not converted. Logos from the theme folder, CSS background images in page builder sections and images pulled from external sites are often missed.
Then rerun your speed test. If the next-gen format warning lists only a few files, you now know exactly which ones the plugin does not reach.
When WebP does not show up
- The page cache is serving old HTML. With the picture or URL methods, cached pages still contain the old image markup until they are cleared. If clearing caches does not seem to change anything, our post on WordPress changes not showing lists every layer that can hold an old copy.
- The rewrite rules are not running. On Nginx, .htaccess files are ignored. On Apache, another rule in .htaccess may come first. The plugin’s status page usually says whether its rules are working.
- The CDN cached the JPEG. If the CDN stored the original before conversion, or does not keep separate versions per browser, it may keep serving JPEG. Purge it, and if the problem continues, switch to the picture method.
- Background images were never touched. Images set in CSS by a theme or page builder are often outside what a plugin can rewrite. Some plugins have an option for this; otherwise replace them with WebP uploads by hand.
- A lazy loading script got in the way. Some lazy load scripts move the image address into a data attribute, and the WebP plugin no longer recognises it. Try disabling one feature at a time.
Undoing it cleanly
If WebP causes trouble, deactivating the plugin should return your site to serving originals, provided you kept them. Afterwards, remove any rewrite rules the plugin added to .htaccess if they were not removed automatically, clear all caches, and check a few pages. Only then delete the WebP copies, if you want the disk space back.
WebP is one part of a lighter page, not the whole story. To see where it sits among the other image fixes, start from our overview of how images slow a website down, and for the bigger picture of caching, scripts and hosting, see the guide to website performance.
Frequently asked questions
Why does my image address still end in .jpg after converting to WebP?
Your plugin is probably using a server rewrite. The page still requests the JPEG address, and the server sends the WebP version to browsers that accept it. Check the Type column and the Content-Type header in the browser’s Network tab rather than the file name. If both say WebP, it is working.
Do I need to convert images again after changing my theme?
Often yes. A new theme may register different image sizes, and when you regenerate thumbnails to create them, the new copies have no WebP versions yet. Most plugins can then rerun the bulk conversion for files that are missing a WebP copy. Clear caches afterwards so pages point at the new files.
Will converting to WebP break images in my emails or on social media?
It should not if your plugin keeps originals and only serves WebP to browsers that ask for it. Newsletter tools and social networks generally fetch the original JPEG or PNG. Problems arise mainly when a plugin replaces image addresses outright without a fallback, so check that setting before you start.
Is it safe to delete the original JPEG files to save space?
It is not a good idea on most sites. Originals act as the fallback, let you reconvert later at a different quality and allow you to remove the plugin without broken images. If disk space is the issue, remove unused media first or ask your host about storage before deleting source files.
On a site with several caching layers, a CDN and a page builder, the delivery side of WebP can take some untangling. Image optimisation and WebP conversion are part of our website speed optimisation service, done with your approval and checked in a before-and-after comparison.
Next in this series: Lazy Loading Images Explained, and the Hero Image Mistake