PageSpeed Insights keeps telling you to "serve images in next-gen formats," your Lighthouse score won't budge past a certain point, and every performance plugin you've tried mentions WebP without really explaining what to do about it inside WordPress specifically. You know WebP is smaller than JPEG and PNG — what's less clear is whether WordPress already handles it, whether you need a plugin, and what happens to the thousands of images already sitting in your Media Library.
The good news is that WordPress has supported WebP natively since version 5.8, so part of this is already solved for you. The part that isn't solved automatically — converting your existing image library and handling the rare browser that doesn't support WebP — is what this guide walks through.
WordPress has supported uploading and displaying WebP images natively since version 5.8 — no plugin needed for new uploads. What native support doesn't do is convert your existing JPEG and PNG library or add fallback handling, which is where a plugin like Imagify, ShortPixel, or WebP Express comes in. For most sites, the fastest path is: let WordPress handle new WebP uploads natively, and use a plugin to convert everything already in your Media Library.
How WebP works in WordPress
Since WordPress 5.8, WebP is treated as a first-class citizen in the Media Library. You can drag a WebP file into Media > Add New, or upload it directly through the Image block, and WordPress will accept it exactly like a JPEG, PNG, or GIF — no extension or third-party code required.
That native support depends on your server's image processing library. WordPress uses either GD or Imagick to generate the thumbnail sizes it needs (thumbnail, medium, large, and so on), and one of those libraries has to support WebP for uploads to work. Nearly every modern WordPress host meets this requirement out of the box, but lossless WebP with full alpha transparency has historically depended on Imagick specifically, since GD's WebP support has been more limited.
The important limitation to understand: native support is about using WebP files you already have — it is not a converter. WordPress will not automatically turn your existing JPEG and PNG images into WebP. For that, you need either a plugin or a host-level optimization feature, both of which we cover below.
Why WebP matters for your WordPress site
WordPress sites are especially image-heavy — featured images, product photos, theme graphics, logos — which makes image weight one of the highest-leverage places to improve performance:
- It's the single biggest lever for Core Web Vitals. Images typically make up close to half of total page weight on a WordPress site, so converting them to WebP is often the fastest way to improve Largest Contentful Paint.
- It directly answers a PageSpeed Insights warning. The "serve images in next-gen formats" recommendation you see in Lighthouse and PageSpeed Insights is specifically asking for formats like WebP.
- It reduces hosting and CDN costs. Smaller media libraries mean less storage and bandwidth, which matters on WordPress sites with large product catalogs or years of blog images.
- It's now a one-time setup, not ongoing manual work. Once native support and a conversion plugin are in place, every future upload is handled automatically.
Step-by-step: setting up WebP on WordPress
- Confirm your host supports WebP. Go to Tools > Site Health > Info > Media Handling in your WordPress dashboard. It reports whether your server's GD or Imagick library was compiled with WebP support. Nearly every modern host — SiteGround, Kinsta, WP Engine, Bluehost — passes this by default; older shared-hosting stacks on outdated PHP builds are the main exception.
- Try a native upload first. Upload a single .webp file through Media > Add New before touching anything else. If it appears in the grid with a working thumbnail, native handling is confirmed end to end and you can move on to the library-wide conversion.
- Choose a conversion method for your existing library. Pick one: a WordPress plugin (Imagify, ShortPixel, WebP Express, or WebP Converter for Media), or a host-level feature such as Cloudflare Polish or Kinsta's built-in image optimization if your host offers it. Running both at once is the single most common source of broken images — see mistake #3 below.
- Run a full Media Library conversion. Most plugins include a bulk-optimize tool that queues every existing image and generates a WebP version alongside the original. On a library with a few thousand images this can take anywhere from a few minutes to over an hour, depending on your host's CPU limits — it's safe to let it run in the background.
-
Enable automatic fallback.
Confirm the plugin serves WebP to supporting browsers and the original JPEG or PNG to the rest, using the HTML
<picture>element with a<source type="image/webp">and a standard<img>fallback. This is on by default in nearly every mainstream plugin, so you're mostly just verifying it rather than configuring it. - Set new uploads to convert automatically. Turn on the plugin's "auto-optimize on upload" setting so every image added from this point forward — through the editor, a page builder, or WooCommerce product imports — gets a WebP version generated without you touching it again.
- Re-run PageSpeed Insights or Lighthouse. Confirm the "serve images in next-gen formats" flag has cleared and compare your new Largest Contentful Paint score against the baseline. Most sites see the biggest single jump here of any performance change they make in a single afternoon.
What the fallback in step 5 is actually doing
Under the hood, most WebP plugins rewrite your image tags into an HTML <picture>
element. The browser checks its own format support first, then picks the matching source —
nothing is decided on the server per visitor.
Common mistakes when adding WebP to WordPress
1. Assuming native support means your old images are already converted
This is the single most common misunderstanding site owners run into. WordPress 5.8+ lets you upload new WebP files, but it does nothing to the JPEG and PNG images already sitting in your Media Library — a site with five years of blog posts can have thousands of untouched images even after "enabling WebP." If you skip a conversion plugin entirely, everything published before that point stays exactly as it was, and your PageSpeed report will keep flagging those older pages.
2. Skipping the fallback and assuming every visitor sees WebP
Browser support for WebP is around 98–99% globally in 2026, which is high but not universal — older Safari versions on unpatched devices, some in-app browsers, and certain embedded/kiosk browsers still don't render it. Most plugins add a fallback automatically at no real cost, so there's little reason to disable it. Turning it off to "simplify" the setup just trades a small performance gain for broken images on a slice of your traffic.
3. Running multiple conversion plugins at once
Stacking two image-optimization tools — for example, a caching plugin's built-in WebP
feature alongside a dedicated conversion plugin like ShortPixel — is a frequent cause of
support tickets. Both tools may try to rewrite the same <img> tags or add
conflicting .htaccess rewrite rules, which can result in duplicate
-webp.webp files cluttering your uploads folder, or images that intermittently
fail to load depending on which plugin's rule fires first. Pick one conversion method per
site and disable WebP handling in everything else.
4. Not checking server requirements before switching hosts or PHP versions
WebP support depends on your server's GD or Imagick configuration, and lossless WebP with transparency specifically depends on Imagick in many setups — GD's WebP handling has historically been more limited, particularly on older builds. If you migrate hosts, downgrade PHP, or move from shared hosting to a container-based host, re-check Site Health to confirm WebP support didn't quietly break. It's an easy thing to miss because the site keeps working — it just silently stops generating new WebP versions.
5. Converting at too aggressive a compression level
Some plugins default to a "maximum compression" preset that pushes lossy WebP quality well below 70. On photographic images this is usually fine, but on graphics with flat colors, text overlays, or sharp gradients — banners, infographics, screenshots — it can introduce visible blocking artifacts. A quality setting of 75–85 is the safer default; drop lower only after spot-checking a few converted images yourself.
Real-world examples
These are representative results from converting a WordPress Media Library from JPEG/PNG to WebP using a conversion plugin:
The pattern across most WordPress sites is consistent: the conversion itself is nearly invisible to visitors, but the effect on page weight and load time is immediate.
Native support vs plugins vs host-level conversion
There are three distinct ways WebP ends up on a WordPress site, and most sites end up using more than one at the same time.
| Method | Handles new uploads | Converts existing library | Fallback included | Setup effort |
|---|---|---|---|---|
| Native WordPress (5.8+) | Yes | No | No | None |
| Conversion plugin (Imagify, ShortPixel, WebP Express, WebP Converter for Media) | Yes | Yes | Yes, usually automatic | Low – install & run bulk convert |
| Host-level / CDN (Cloudflare Polish, Kinsta Image Optimization) | Yes | Yes, on the fly | Yes | Very low – toggle setting |
Convert your images to WebP before uploading — free
If you'd rather prepare images before they ever touch your Media Library, the Rebrixe Image Converter runs entirely in your browser. Convert JPEG or PNG to WebP, or go the other direction for compatibility — your images are never uploaded to a server. No account, no file size limit, no watermarks.