How to serve WebP from WordPress without server configuration
Most WebP guides for WordPress start with server rewrite rules. On many hosts you cannot change those, and you do not have to.
Short answer
Create WebP copies of your images when they are uploaded, then swap image URLs in the HTML for browsers that accept WebP. Our free Auto WebP plugin does both in PHP through WordPress filters, so no .htaccess or Nginx rules are needed. It also bulk-converts existing media. WebP reduces image weight, but it will not fix oversized images or slow servers.
On this page5 sections
What WebP changes
WebP is an image format developed by Google. It supports lossy and lossless compression as well as transparency, and every current major browser can display it. At similar visual quality, WebP files are usually smaller than the equivalent JPEG or PNG, which means fewer bytes to download, especially on phones and slow connections.
The usual obstacle on WordPress is not the format but delivery. Many guides rely on .htaccess rewrite rules or Nginx configuration to send a WebP file when the browser asks for a JPEG. That works, but it depends on the server, and on managed or shared hosting you often cannot change it.
How Auto WebP works
Auto WebP is a small, free plugin we wrote to remove that dependency. It needs WordPress 5.0 or later, PHP 7.4 or later, and either GD or Imagick with WebP support. It does four things:
- Converts on upload. When you upload a JPEG, PNG or GIF, it creates WebP copies of every image size WordPress generates, next to the originals:
photo.jpggets aphoto.webp. The originals stay. - Serves WebP to browsers that accept it. If the browser’s request says it accepts
image/webp, the plugin swaps image URLs in the HTML through standard WordPress filters: attachment images, theirsrcset, and upload URLs inside post content. There is no redirect and no rewrite rule, so it behaves the same on Apache, Nginx and LiteSpeed. - Bulk-converts existing media in batches, with a progress bar, so a large library does not run into timeouts.
- Cleans up. When you delete an image from the Media Library, its WebP copies go with it.
Quality is adjustable and defaults to 82. The Media Library gets a column showing each image’s WebP status and how much space it saved, and single images can be converted with one click. Conversion uses GD, with Imagick as a fallback. To check whether your PHP build can write WebP with GD, run:
php -r 'var_dump(function_exists("imagewebp"));'
The plugin’s settings page also shows which conversion engine it found.
Two caveats worth knowing
First, the swap happens when WordPress renders the page. Images that never pass through WordPress’s media functions, such as a background image in a theme stylesheet or a hard-coded path in a template, keep their original format. Those need to be converted and referenced by hand.
Second, full-page caching. Because the HTML depends on the browser’s Accept header, a page cache or CDN stores whichever version was rendered first and serves it to everyone. Current browsers accept WebP, so this rarely matters in practice; whether an old browser still gets a JPEG or PNG depends on how your cache or CDN varies its responses, so check that if you need to support one.
Responsive images do much of the work
A WebP that is three times wider than the space it fills is still too large. Responsive images solve that: the srcset and sizes attributes let the browser choose the smallest file that will look sharp on that screen. WordPress adds them to the images it outputs, using the sizes it generates on upload. Auto WebP converts all of those sizes, so the browser still chooses, just between WebP files.
Where themes often go wrong:
- printing a full-size image directly instead of using WordPress’s image functions, which loses
srcset; - a
sizesvalue that does not match the layout, so the browser downloads a bigger file than it needs; - missing
widthandheightattributes, which lets the page jump as images load.
What WebP alone will not fix
Image weight is one part of page speed. Lighter images will not help with:
- a slow Largest Contentful Paint caused by a lazy-loaded hero image, a slow server response, or render-blocking CSS and JavaScript;
- layout shift from images, ads or embeds without reserved space;
- heavy third-party scripts such as chat widgets, trackers and tag managers;
- a theme or plugin stack that does a lot of work on every request.
The hero image deserves particular attention. It is often the largest element on the screen, so it should not be lazy-loaded and should be served at the right size. Converting it to WebP helps; making sure the browser requests it early often matters just as much.
WebP is a sensible default and an easy improvement on almost any WordPress site, but it is the start of performance work, not the end. If your site is still slow once images are sorted, our fixes and improvements and support and maintenance services cover the rest. Send us a link to start.
Requirements: Auto WebP on WordPress 5.0+, PHP 7.4+, GD or Imagick with WebP support
Key takeaways
- Auto WebP creates WebP copies on upload and swaps URLs through WordPress filters, with no rewrite rules.
- Images outside WordPress's media functions, such as theme CSS backgrounds, keep their original format.
- Full-page caches store whichever version was rendered first, which matters only if you support very old browsers.
- Correct sizes, srcset and an early-loading hero image matter as much as the file format.
