Fix ‘serve images in next gen formats’ in WordPress

So PageSpeed Insights just flagged your site for “serve images in next-gen formats” (or ‘modern formats’ as it’s now called), and now you’re here looking for a way to fix it.

The thing to understand is that passing this audit involves two separate jobs. First, you convert your image files to a smaller format. Second, you deliver the correct format to each visitor’s browser. Both have to work, and most fixes fall apart at the second step.

This guide walks you through everything you need to take care of this issue: 

• What the warning actually means.
• Plugin options.
• How to verify the fix in Chrome DevTools.
• Troubleshooting the cases where the warning won’t budge.
• A manual .htaccess route for developers who’d rather skip another plugin.

What does ‘serve images in modern formats’ mean?

Despite the alarming tone, the warning points to something simple: Your images are larger than they need to be, and a more efficient format would reduce their size without a visible drop in quality.

The mechanics have shifted over the past year. Older versions of Lighthouse ran a dedicated audit that looked at your JPEGs and PNGs, estimated how small each one would be as a WebP or AVIF, and reported the potential savings. 

As of Lighthouse 13, that standalone audit has been folded into a broader check called the Improve image delivery insight. It still flags oversized images, but it now covers more ground: Compression level, modern formats, responsive sizing, and swapping heavy animated GIFs for video.

The savings are real. WebP files typically run 25–34% smaller than an equivalent JPEG, and AVIF can go further still on photographs. For example, the original size of the image below was 830 KB. In the WebP format at 75% quality, it was 401 KB, and in the AVIF format at 50% quality, it was 277 KB. 

This is quite important because when an image is your largest element on screen, a smaller, properly delivered file can improve your LCP—though LCP also depends on how quickly that image is discovered, prioritized, and served.

Why WordPress doesn’t serve WebP or AVIF by default

First, let’s define the two formats:

• WebP is the older and safer of the two. It compresses images roughly 30% smaller than an equivalent JPEG or PNG, supports both lossy and lossless modes, and works in every modern browser.
• AVIF is the newer arrival. It pushes compression further—up to 50% smaller than JPEG at the same quality—and handles a wider color range, including HDR.

So if WordPress understands both formats, why is PageSpeed still nagging you?

Because “support” here means something narrower than people expect. WordPress 5.8 added WebP uploads in 2021, and 6.5 added AVIF uploads in 2024. That’s the whole feature: You can upload a WebP or AVIF file and use it like any other image. What WordPress won’t do on its own is convert your existing media library, generate next-gen copies of the JPEGs you uploaded years ago, or decide which format to serve each visitor based on what their browser supports.

That last gap is the one PageSpeed keeps catching. Your install can be fully up to date and still fail the audit, because the files already sitting in your library never got converted, and nothing is choosing the right format per browser.

The plugin approaches for converting your images

The most reliable way to serve images in next-gen formats in WordPress is to install a plugin that handles both jobs for you: Converting your images to WebP or AVIF, and then delivering the smaller version to each browser automatically. 

If you want a starting point before comparing the details, three tools cover most situations:

• EWWW Image Optimizer: the well-known free option. You get unlimited local compression, lossless JPG, PNG, GIF, and SVG image optimization, and WebP conversion. AVIF quality is only configurable in the premium plan. 
• Imagify: a popular choice once you’re paying, with a small free tier. Automatically converts images to WebP or AVIF on their own servers. 
• NitroPack: the all-in-one route. WebP conversion is included free for up to 1,000 pageviews a month, and it comes bundled with caching and a CDN rather than working as a standalone image optimization tool.

Now, each of these plugins handles both conversion and delivery, but they don’t all deliver in the same way. And delivery is where the majority of failures happen—the conversion runs fine, but the right file never reaches the browser.

There are four delivery methods in common use, and which one works depends entirely on your hosting:

1. .htaccess server-side rewrites detect WebP support and swap the file at request time. Clean when it works, but it breaks on Cloudflare and most managed-host caching unless the server or CDN is set to vary its responses by browser support.
2. <picture> tag rewriting edits the HTML so the browser picks the format itself. It works on any server, but it can’t touch images set as CSS backgrounds.
3. JavaScript rewriting swaps URLs at runtime and catches more edge cases, including some page-builder images. The trade-off is an added runtime cost, which makes it a poor fit for critical hero or LCP images.
4. CDN-layer delivery sidesteps the whole decision by handling format negotiation at the edge. NitroPack works this way, as do Cloudflare Polish and BunnyCDN.

With those delivery methods in mind, here’s how the main plugins compare with each other: 

Tool	Free tier reality	Default delivery method	AVIF	Best for	Gotcha
NitroPack	1,000 pageviews/mo, WebP included	CDN layer	No (WebP only)	One tool for images, caching, and CDN	Changes more on your site than the alternatives
Imagify	20MB (~200 images)/mo	<picture> tags	Yes	WP Rocket users	Free tier runs out fast on image-heavy sites
ShortPixel	100 credits/mo	<picture> tags (.htaccess optional)	Yes, via their CDN	Credit-based flexibility	Credit pricing is less predictable than a flat fee
EWWW Image Optimizer	Unlimited local compression	Choice of all three (.htaccess, <picture>, JS)	Paid only (Easy IO)	Hosting flexibility	More settings to navigate
Smush	No next-gen formats on free	Smush CDN (Pro)	Pro only	Sites already in the WPMU DEV ecosystem	Free version won’t clear this audit
Converter for Media	Free (WebP); AVIF needs Pro	.htaccess rewriting	Pro only	Apache/LiteSpeed hosts wanting free server-level rewriting	Less polished UI
WebP Express	Fully free	Choice (.htaccess, <picture>, URL rewriting)	No (WebP only)	A single-purpose free tool	WebP only, no AVIF

If you read only one column, make it the delivery method. That’s what decides whether a plugin actually works on your host, and it’s the reason so many people convert every image, re-run the test, and still see the warning staring back at them.

Which is exactly the problem the next section solves.

How to verify WebP delivery in Chrome DevTools

Re-running PageSpeed Insights tells you whether you passed. It doesn’t tell you which images were converted and which slipped through. Chrome DevTools does, in about thirty seconds, by showing you exactly what your browser downloaded.

Here’s the check:

1. Open DevTools—right-click anywhere on the page and choose Inspect, or press Cmd/Ctrl + Shift + I.

2. Switch to the Network tab.

3. Reload the page with Cmd/Ctrl + R, so DevTools captures every request.
4. Click the Img filter to show only images.

5. Read the Type column. For any photo or raster image you expect your plugin or CDN to convert, it should say webp or avif—not jpeg or png.

That column is your fast glance. For certainty, click an individual image request, open the Headers tab, and look under Response Headers: the content-type should read image/webp or image/avif. That’s the server confirming what it actually sent, which is harder to misread than a file extension.

Once DevTools confirms the right formats are going out, re-run PageSpeed Insights or Lighthouse to see whether the page still trips the Improve image delivery insight under Google’s own test conditions.

What to do when the PageSpeed warning persists

You ran the bulk conversion, the plugin said it finished, and DevTools still shows JPEGs going out. So, the conversion obviously worked, but something downstream is undoing it. Almost always, it’s one of three things.

The delivery method doesn’t match your host

This is the usual culprit. If your plugin is set to .htaccess rewrites, that method can quietly fail when Cloudflare, another CDN, NGINX, Varnish, or a managed host’s cache serves up cached images without varying by whether the browser supports WebP. It isn’t universal—some hosts and paid CDN features handle WebP at the edge perfectly well—but it’s common enough to check first. 

What to do: Switch your plugin’s delivery method to <picture> tags or JS rewriting, both of which sidestep the server-config problem.

The stubborn images come from a slider, page builder, or theme header

Page builders often output images without the wp-image-{ID} class that conversion plugins rely on to find and rewrite URLs, so those images quietly skip the process. It’s documented for Elementor specifically, where the image markup omits that class, and the format swap never happens. 

What to do: Re-upload the offending images through the standard Media Library, or check whether your plugin has a compatibility setting for your specific builder.

Old thumbnails never got converted

Every image size WordPress generated before you installed the plugin still exists as the original JPEG or PNG. 

What to do: Run a thumbnail regeneration tool, then trigger bulk conversion again so those older sizes get swept up too.

How NitroPack handles conversion and delivery in one step

Every tool in the section above delivers images from one of two places: Your own server (.htaccess rewrites) or your page’s HTML (<picture> tags and JS rewriting). That’s exactly why a cache or CDN sitting in front of them can intercept the result.

NitroPack takes a different route. It converts and delivers images from its own CDN, so the format negotiation happens at the edge rather than on your server. The host-environment failure modes from the last section—the Cloudflare conflicts, the managed-host caching, the .htaccess rules that quietly stop working—fall away, because delivery never depends on your server config in the first place.

The free plan covers 1,000 pageviews a month with WebP conversion, Preemptive Image Sizing, and Lazy Loading included—no per-image credits, no card required. Two of the more advanced image features, Adaptive Image Sizing and LCP Preload, sit on the Plus plan ($22/month), so the free tier handles the next-gen conversion this article is about, just not the full image stack.

Important to note: NitroPack converts to WebP, not AVIF. If AVIF is a hard requirement for you, one of the other tools above may be a better fit.

There are other ways to deliver at the CDN level: Cloudflare Polish (Pro and up) and BunnyCDN do the same thing. However, the difference is the bundle: Caching, CDN delivery, lazy loading, and code optimization come as a single subscription rather than a stack of separate plugins. And if you ever uninstall, your originals come back, because NitroPack keeps them as the fallback.

Getting it running takes three steps:

1. Install the NitroPack plugin—the free plan is enough to start.
2. In the dashboard, open Image Optimization and select your compression level.

3. Trigger the purge cache option from the dashboard.

You don’t need to do anything more than that—NitroPack converts to WebP automatically. 

The .htaccess route for Apache hosts

If you’d rather not add another plugin and you’re comfortable in a config file, there’s a manual route. It only applies to Apache or LiteSpeed hosts with mod_rewrite enabled, and it covers delivery, not conversion (more on that in a second).

The idea is simple – check whether the visitor’s browser accepts WebP, and if a matching .webp file exists, serve that instead of the original:

# Serve existing WebP files for JPG/PNG requests when the browser supports WebP.
# Put this above the WordPress block in the root .htaccess file.

<IfModule mod_mime.c>
  AddType image/webp .webp
</IfModule>

<IfModule mod_setenvif.c>
  SetEnvIfNoCase Request_URI "\.(jpe?g|png)$" WEBP_CANDIDATE
</IfModule>

<IfModule mod_headers.c>
  Header merge Vary Accept env=WEBP_CANDIDATE
</IfModule>

<IfModule mod_rewrite.c>
  RewriteEngine On

  RewriteCond %{HTTP_ACCEPT} image/webp [NC]
  RewriteCond %{REQUEST_FILENAME} ^(.+)\.(jpe?g|png)$ [NC]
  RewriteCond %1.webp -f
  RewriteRule ^(.+)\.(jpe?g|png)$ $1.webp [END,NC]
</IfModule>

For this snippet, use the following naming pattern:

• image.jpg  → image.webp
• image.png  → image.webp

Here’s the part that trips people up. This rule only rewrites requests to WebP files that already exist on disk. It doesn’t create anything. You still have to generate the WebP versions yourself first, either with WP-CLI image commands or by converting locally (Squoosh or the cwebp CLI) before re-uploading.

On Nginx, the approach is different and needs a map directive plus a location block. Seravo publishes a working configuration for both WebP and AVIF.

One warning before you commit to this: it’s the same failure mode from earlier. If a CDN, reverse proxy, Varnish layer, or managed-host cache sits in front of Apache and doesn’t vary its cached responses by browser support, it may serve the wrong cached format. On Cloudflare, you’ll need Vary for Images or a different setup. And on WP Engine, custom .htaccess isn’t the right path at all, since they use server-level caching by default. Use their supported WebP/CDN features or ask their support team for the correct server-level config.

Frequently asked questions

Should I use WebP or AVIF?

For photographs, lossy AVIF usually produces the smaller file, assuming your conversion tool supports it well. But WebP is the safer default for most WordPress sites: It has broader plugin support and fewer edge cases. 

The one place the “AVIF always wins” advice falls apart is lossless images—a lossless AVIF can end up larger than a well-optimized PNG, so it’s not a blanket upgrade. Match the format to the image rather than chasing the newest one.

What quality setting should I use?

For JPEG and WebP photos, 75–85 is the range to start in—then look at the result and adjust by eye. AVIF is trickier, because its quality scale doesn’t map onto the same numbers; use your tool’s recommended default and judge the output rather than the slider. The setting you’re after is always the same one: The smallest file that still looks good for that image.

Will conversion break older browsers?

Not if it’s set up properly. Every legitimate delivery method—<picture> tags, .htaccess content negotiation, CDN logic—falls back to the original format when a browser doesn’t support the next-gen one. And that’s an increasingly small audience: Modern browsers now cover the majority of traffic.

Should I keep my original JPEGs?

Yes. You’ll want the originals for browser fallback, for email and RSS exports that don’t handle next-gen formats, and as your way back if you ever uninstall the optimization tool. Storage is cheap; re-creating lost originals isn’t.

By Lora Raykova

User Experience Content Strategist

Lora has spent the last 8 years developing content strategies that drive better user experiences for SaaS companies in the CEE region. In collaboration with WordPress subject-matter experts and the 2024 Web Almanac, she helps site owners close the gap between web performance optimization and real-life business results.