Why WebP matters and how to serve it on WordPress

Here is a number worth sitting with: switching a typical photo-heavy page from JPEG to WebP cuts its image weight by roughly 30%, with no quality difference a visitor could ever spot. WebP has around 97% browser support in 2026. And yet a large share of WordPress sites still serve JPEG and PNG to every visitor, leaving that 30% on the table on every single image, on every single page view, forever. Image weight is the biggest single factor in how fast a page loads, so this is not a rounding error — it is one of the largest free performance wins available to a WordPress site, and most sites have not claimed it.

This guide explains what WebP actually is, why it wins, the three ways to serve it on WordPress with the trade-offs of each, when not to use it, and how it behaves at gallery scale. It pairs with our AVIF versus WebP comparison for the “what comes after WebP” question, and sits inside the broader guide to gallery page speed.

What WebP is, and why it compresses harder

WebP is a modern image format developed by Google specifically to shrink web images. It does two jobs that previously needed two formats: lossy compression for photographs (the job JPEG does) and lossless compression with transparency for graphics and logos (the job PNG does). That alone is useful — one format covers both cases — but the real win is that it does each job with better compression than the format it replaces.

The reason it compresses harder is technical but worth understanding at a high level: WebP uses smarter prediction (guessing each block of pixels from its neighbours and storing only the difference) and more efficient encoding of the result than the decades-old JPEG algorithm. The practical upshot is that for a photograph at the same visual quality, WebP typically produces a file around 25–35% smaller than JPEG, and for a flat PNG graphic the saving can be far larger. Across a page, or a gallery, those per-image savings stack into a meaningfully lighter, faster page.

A worked example

Take a portfolio page with twenty photographs, each a 1,600-pixel JPEG at around 400KB — a total of roughly 8MB of images. Converted to WebP at the same display quality, those same twenty images come in around 280KB each, or roughly 5.6MB total. That is 2.4MB shaved off the page with no visible change to the photos. On a fast desktop connection the visitor might not consciously notice; on a mid-range phone on mobile data, 2.4MB is the difference between a page that feels instant and one that feels like it is still arriving. And because the largest image is usually the Largest Contentful Paint element, a smaller hero image directly improves the Core Web Vitals score Google measures.

The fallback pattern: WebP never breaks old browsers

A common worry is that serving WebP will break the page for someone on an old browser. It will not, as long as you serve it the standard way — with a fallback. You never ship WebP alone; you offer it alongside a JPEG or PNG, and the browser picks the first format it understands.

The mechanism is the HTML <picture> element, which lists multiple sources in order of preference. A simplified version looks like this:

<picture>
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Descriptive alt text">
</picture>

A browser that understands WebP loads photo.webp; one that does not falls through to the photo.jpg inside the <img> tag. In practice you almost never hand-write this — your image plugin, CDN, or server generates it for you. But it is worth knowing the shape, because it explains why “serve WebP” and “support old browsers” are not in tension. The fallback is built into how the format is meant to be delivered. With WebP support at ~97%, the fallback fires for a small and shrinking minority, and they still get a perfectly good image.

How WordPress handles WebP — and what it leaves to you

WordPress has supported WebP since version 5.8: you can upload WebP files directly, and the media system can generate WebP versions of the intermediate sizes it creates. That is genuinely helpful, but it is also where a lot of site owners assume the job is done when it is not. Two gaps remain.

First, WordPress core does not automatically convert the JPEG and PNG library you have already built up. Every image you uploaded before switching is still served in its original format. Second, core does not automatically serve a WebP version in place of an existing JPEG on the front end — the substitution-with-fallback behaviour is not built in. So “WordPress supports WebP” means “you can use WebP,” not “your site is now serving WebP.” Closing those two gaps — bulk-converting the existing library, and serving WebP with a fallback — is the job of a plugin, a CDN, or server configuration.

Three ways to serve WebP, and how to choose

1. A plugin (the common route)

An image-optimisation or gallery plugin converts your images to WebP — on upload for new images, and in a bulk pass for the existing library — and serves them with a JPEG fallback. This is the route most sites take because it is the simplest: install, run the bulk conversion once, and new uploads are handled automatically thereafter. The trade-off is an extra plugin to maintain and, depending on the plugin, stored WebP duplicates that use some additional disk space. For most WordPress sites this is the right balance of effort and control.

2. A CDN (best if you already run one)

A content delivery network with image optimisation converts images to WebP on the fly, at the edge, often detecting each browser’s support automatically and serving the right format without storing duplicates on your server. If you already run a CDN — and an image-heavy site probably should, as we cover in the CDN strategy guide — this is efficient and keeps the conversion logic off your origin. The trade-off is the dependency: the format selection lives at your CDN provider, so you are tied to that service for it.

3. Server-level (most control, most technical)

Your host or server can convert images and serve WebP through server rules that detect browser support and swap the format transparently. This gives the most control and avoids both an extra plugin and a third-party dependency, but it requires server access and comfort editing configuration. It is the route for developers and managed hosts that offer it as a feature; most site owners will not take it, and that is fine.

Convert on upload, or on the fly?

Cutting across those three routes is one more decision. Converting on upload generates the WebP once and stores it, so every subsequent visit serves a pre-made file quickly and cheaply — at the cost of a moment’s processing per upload and some extra storage. Converting on the fly (typically at a CDN) stores no duplicates and selects the format per request automatically, at the cost of a dependency and a tiny per-request overhead. For most sites, on-upload conversion is the more predictable choice; very high-traffic sites already on a CDN often prefer on-the-fly. Neither is wrong — they optimise for different things.

When not to use WebP

WebP is the right default for photographic content, but it is not universal. A few honest exceptions:

• Simple flat graphics and icons — a small, flat logo may already be smaller as an optimised SVG (which is also infinitely scalable) or even a tiny PNG. Convert by all means, but the win is marginal here.
• Images you are about to serve as AVIF — if you are setting up the AVIF → WebP → JPEG chain, WebP becomes the middle fallback rather than the top choice. You still generate it; it just is not the primary format. See the AVIF comparison.
• Images that must be edited by third parties in a specific format — if a downstream tool or partner requires JPEG, keep a JPEG master; serve WebP to the browser, but do not lose the original.

None of these are reasons to avoid WebP across the site — they are narrow cases where you make a deliberate exception. The default remains: photographs and most content images should be served as WebP with a fallback.

WebP at gallery scale

Everything above multiplies in a gallery. A single image at 30% smaller is a nice saving; a 200-image gallery at 30% smaller is a transformed page. This is also where the conversion approach matters most, because nobody is going to hand-convert two hundred images, and a bulk conversion that has to re-process a large library is a real (if one-time) job. The sustainable answer for an image-heavy site is automatic conversion: new gallery images become WebP on upload, the existing set is converted once in a batch, and you never think about it again.

This is exactly the kind of work worth delegating to the gallery plugin rather than bolting on a separate tool. FotoGrids handles automatic WebP and AVIF conversion with fallbacks in its Pro Plus tier, so every gallery image is served in a modern format without a manual export step or a second optimisation plugin — the saving applies across the whole gallery by default. (If you are still on the free tier, the free responsive-images and lazy-loading features already help; format conversion is the Pro Plus addition.)