
How to use WebP images in WordPress?
You can use WebP images in WordPress in three main ways: upload WebP files directly to the Media Library (supported natively since WordPress 5.8), let a plugin convert your JPEG and PNG images to WebP automatically, or configure WordPress or your server to generate and serve WebP versions for you. All modern browsers support WebP, so for most sites the only real question is which method fits your workflow.
WebP is one of the easiest ways to shrink image file sizes without a visible drop in quality. This article explains what WebP is, how to check that your server supports it, and how to use it in WordPress with and without plugins, including server rules for Apache and Nginx and a few pitfalls to watch out for.
What Is WebP?
WebP is an image format developed by Google that supports both lossy and lossless compression, transparency (alpha channel), and animation. In practice, it can replace JPEG, PNG, and animated GIF in most situations while producing noticeably smaller files.
Key characteristics of WebP:
- Lossy mode: Similar to JPEG, suitable for photographs, usually with smaller files at comparable visual quality.
- Lossless mode: Similar to PNG, suitable for graphics and screenshots, often smaller than the equivalent PNG.
- Transparency: Unlike JPEG, WebP supports transparent backgrounds even in lossy mode.
- Animation: WebP can store animations, typically far more efficiently than GIF.
Exact savings depend on the image, but it's common to see meaningful reductions compared to well-optimized JPEGs and larger reductions compared to PNGs.
Why Should You Use WebP in WordPress?
Switching to WebP brings practical benefits:
- Faster page loads: Smaller images mean less data to download, which directly improves load times and Largest Contentful Paint.
- Better Core Web Vitals: Tools like PageSpeed Insights specifically recommend serving images in next-gen formats.
- Lower bandwidth usage: Useful on hosting plans or CDNs that charge by data transfer.
- Broad browser support: Chrome, Firefox, Safari, Edge, and their mobile versions all support WebP, so fallbacks are mostly a safety net for very old browsers and some email clients or third-party tools.
Does WordPress Support WebP?
Yes. WordPress added native WebP upload support in version 5.8. That means you can upload .webp files to the Media Library just like JPEGs and PNGs, insert them with the Image block, and WordPress will generate resized WebP copies for responsive srcset output.
There is one important condition: your server's image library must support WebP. WordPress uses either Imagick (ImageMagick) or GD to process images. If neither supports WebP, you may see an error like "This image cannot be processed by the web server" when uploading.
How to Check WebP Support on Your Server
- Go to Tools > Site Health in your WordPress dashboard.
- Click the Info tab.
- Expand the Media Handling section.
- Look for the active editor (Imagick or GD) and the list of supported file formats. WebP should appear there.
If WebP isn't listed, ask your hosting provider to enable WebP support in Imagick or GD. Most modern hosts already have it enabled.
Method 1: Upload WebP Images Directly
The simplest approach is to convert images to WebP before uploading them.
- Convert your image: Use a tool such as Squoosh (browser-based), Photoshop (which can export WebP in recent versions), GIMP, Affinity Photo, or the command-line
cwebptool. - Upload to WordPress: Go to Media > Add New Media File or drag the file into an Image block in the editor.
- Add alt text: Describe the image as you normally would.
- Insert and publish: WordPress will output the WebP image along with responsive sizes.
Converting Images With cwebp
If you're comfortable with the terminal, Google's cwebp tool is fast and precise. You can install it via your system's package manager (it's part of the webp package on many systems) and run:
# Convert a single JPEG to WebP at quality 80
cwebp -q 80 photo.jpg -o photo.webp
# Convert every JPEG in the current folder
for file in *.jpg; do
cwebp -q 80 "$file" -o "${file%.jpg}.webp"
done
A quality between roughly 75 and 85 is a sensible starting point for photos. For screenshots or graphics, try lossless mode with the -lossless flag.
Pros of this method: No plugins, full control over quality, and no extra files on the server.
Cons: It's manual, and it doesn't help with images already in your Media Library.
Method 2: Use a Plugin to Convert and Serve WebP
For most site owners, a plugin is the easiest way to adopt WebP across an entire site, including older uploads. These plugins generally work in one of two ways:
- Replace originals: Convert the uploaded image to WebP and use it in place of the JPEG or PNG.
- Create copies and serve conditionally: Keep the original and generate a
.webpcopy alongside it, then serve the WebP version to browsers that support it using rewrite rules or<picture>tags.
Well-known plugins that handle WebP include:
Converter for Media: Dedicated to converting images to WebP (and AVIF in its paid version) and serving them through rewrite rules, without changing image URLs in your content.
EWWW Image Optimizer: Can generate WebP copies on your server and deliver them through rewrite rules, JavaScript, or <picture> tags.
ShortPixel Image Optimizer: Creates WebP and AVIF versions through its cloud service and can deliver them with <picture> tags or rewrite rules.
Imagify: Converts images to WebP or AVIF and can display them using <picture> tags or rewrite rules.
Smush: Offers WebP conversion as part of its Pro features, along with compression and lazy loading.
Performance Lab and Modern Image Formats: Plugins from the WordPress Performance Team that let you choose the output format for generated image sizes, including WebP and AVIF, and use the <picture> element for fallbacks.
Typical Setup Steps
While each plugin has its own interface, the process usually looks like this:
- Back up your site, especially the
wp-content/uploadsfolder. - Install and activate the plugin from Plugins > Add New Plugin.
- Open the plugin's settings and enable WebP conversion.
- Choose a delivery method: Rewrite rules are fast and keep your HTML unchanged, while
<picture>tags work on almost any server but change your markup. - Run a bulk conversion to create WebP versions of existing images.
- Clear your caches, including page cache and CDN cache.
- Verify that WebP is being served (see the testing section below).
Method 3: Make WordPress Generate WebP Sub-Sizes With Code
If you prefer not to use a plugin, WordPress includes the image_editor_output_format filter (added in 5.8) that controls which format generated image sizes are saved in. The following code tells WordPress to save resized copies of JPEG and PNG uploads as WebP.
Add it to your child theme's functions.php file or, preferably, a small custom plugin:
<?php
/**
* Plugin Name: Sajjad WebP Sub-Sizes
* Description: Saves generated sub-sizes of JPEG and PNG uploads as WebP.
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
function sajjad_webp_output_format( $formats ) {
$formats['image/jpeg'] = 'image/webp';
$formats['image/png'] = 'image/webp';
return $formats;
}
add_filter( 'image_editor_output_format', 'sajjad_webp_output_format' );
A few things to know about this approach:
- Only new uploads are affected: To convert sub-sizes for existing images, regenerate thumbnails after adding the code.
- The original file stays as uploaded: The full-size original keeps its format, while generated sizes become WebP. Since most content uses a generated size, this covers the majority of front-end output.
- No fallback is created: Because nearly all browsers support WebP, this is usually fine, but it's worth knowing.
- Server support is required: If your image library can't write WebP, WordPress will fall back to the original format.
You can also control WebP quality with the wp_editor_set_quality filter:
function sajjad_webp_quality( $quality, $mime_type ) {
if ( 'image/webp' === $mime_type ) {
return 80;
}
return $quality;
}
add_filter( 'wp_editor_set_quality', 'sajjad_webp_quality', 10, 2 );
Method 4: Serve WebP With Server Rewrite Rules
If you already have .webp copies sitting next to your originals (for example, photo.jpg and photo.jpg.webp or photo.webp), you can let the web server swap them in automatically for browsers that send image/webp in their Accept header. Plugins often write these rules for you, but here's how they work.
Apache (.htaccess)
This example assumes WebP copies are stored with the full original name plus .webp, such as photo.jpg.webp. Add it to your .htaccess file above the # BEGIN WordPress block, and back up the file first:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_URI} \.(jpe?g|png)$
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,L]
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(jpe?g|png)$">
Header append Vary Accept
</FilesMatch>
</IfModule>
<IfModule mod_mime.c>
AddType image/webp .webp
</IfModule>
The Vary: Accept header tells caches and CDNs that the response depends on what the browser accepts, so they don't serve WebP to a browser that can't handle it.
Nginx
On Nginx, you typically use a map in the http block and a try_files rule in your server block:
# In the http {} block
map $http_accept $webp_suffix {
default "";
"~*webp" ".webp";
}
# In the server {} block
location ~* ^/wp-content/uploads/.+\.(png|jpe?g)$ {
add_header Vary Accept;
try_files $uri$webp_suffix $uri =404;
}
Reload Nginx after testing the configuration with sudo nginx -t. If you're on managed hosting, you may not have access to the Nginx config, in which case a plugin using <picture> tags is the easier route.
Using the Picture Element for Fallbacks
The <picture> element lets the browser choose the first source it supports. This is how many plugins provide fallbacks without server rules. If you're writing custom HTML in a Custom HTML block or a theme template, it looks like this:
<picture>
<source srcset="/wp-content/uploads/2026/09/coffee-mug.webp" type="image/webp">
<img
src="/wp-content/uploads/2026/09/coffee-mug.jpg"
alt="Blue ceramic coffee mug on a wooden table"
width="1200"
height="800"
loading="lazy"
>
</picture>
Browsers that support WebP load the <source>, and anything else falls back to the <img>. Keep the width, height, and alt attributes on the <img> tag.
How to Check That WebP Is Being Served
After setting everything up, confirm it's working:
- Open your site in Chrome or Firefox and open developer tools.
- Go to the Network tab and filter by Img.
- Reload the page and click an image request.
- Check the response headers: The
Content-Typeshould beimage/webp, even if the URL still ends in.jpgwhen using rewrite rules. - Run PageSpeed Insights: The "Serve images in next-gen formats" recommendation should shrink or disappear.
If you use a CDN such as Cloudflare, make sure the CDN respects the Vary: Accept header or uses its own image format conversion, otherwise it may cache one format and serve it to everyone.
What About AVIF?
AVIF is a newer format that often compresses even better than WebP. WordPress supports AVIF uploads in recent 6.x releases, again depending on your server's image library. Many optimization plugins can generate both AVIF and WebP and serve the best supported format. WebP remains the safer default thanks to faster encoding and very broad support, and AVIF is a good next step once your WebP setup is working.
Common WebP Issues and How to Fix Them
"This image cannot be processed by the web server": Your server's Imagick or GD library doesn't support WebP. Check Tools > Site Health > Info > Media Handling and ask your host to enable it.
Images still showing as JPEG: Clear page, plugin, browser, and CDN caches. If you're using rewrite rules, confirm the .webp files actually exist and that your server is Apache with mod_rewrite or has the equivalent Nginx rules.
Broken images after deactivating a plugin: If a plugin replaced originals or rewrote URLs in the database, deactivating it can leave broken references. Check the plugin's documentation for a clean uninstall or restore option before removing it.
Colors look slightly different: Some conversions strip color profiles. Most tools have an option to preserve the ICC profile if color accuracy matters.
Social previews not showing WebP: Some social platforms and email clients have inconsistent WebP support. For Open Graph images, a JPEG or PNG is still the safest choice.
FAQ: WebP Images in WordPress
Yes. WordPress has supported WebP uploads natively since version 5.8, as long as your server's image library (Imagick or GD) supports the format.
All current major browsers, including Chrome, Firefox, Safari, and Edge, support WebP. Only very old browsers lack support, which is why some setups still include a JPEG or PNG fallback.
Lossy WebP removes some data, but at a quality of around 75 to 85 the difference is usually hard to see. Lossless WebP keeps full visual quality with smaller savings.
It's safer to keep them. Originals let you re-convert with different settings later, provide fallbacks, and protect you if you ever switch plugins or formats.
If your setup uses server rewrite rules, the URL stays the same but the server sends the WebP file instead. Check the Content-Type response header in your browser's developer tools to confirm.
AVIF often produces smaller files than WebP, but encoding is slower and support depends on your server. Many sites use WebP as the default and add AVIF through a plugin that serves the best format each browser supports.
Conclusion
Using WebP in WordPress is easier than ever. You can upload WebP files directly, let a plugin convert your whole library, add a small filter so WordPress generates WebP sub-sizes, or configure your server to serve WebP copies automatically. Each approach reduces image weight and helps your pages load faster.
For most sites, the best path is to confirm WebP support in Site Health, choose one reliable plugin or the core filter approach, bulk-convert your existing images, and then verify the results in your browser's developer tools. Once WebP is running smoothly, you can explore AVIF for even more savings.


