WebP vs JPEG in WordPress: Which Format Actually Loads Faster
Swap every JPEG to WebP and your site loads faster. That's the received wisdom, and it's mostly true, but the detail matters more than the headline. File size alone doesn't tell you what a browser actually does with the image, and the wrong conversion settings can shave 10kb off a file while quietly introducing a quality problem that puts visitors off. Here's how the two formats actually compare inside a WordPress install, and where each one earns its place.
On this page
What the Size Difference Actually Looks Like
The 25-35% figure people quote for WebP is real, but without a concrete example it stays abstract.
Take a typical product photograph saved as a JPEG at quality 80. At around 1200 pixels wide, that file commonly lands somewhere between 180 KB and 250 KB depending on the image content. Export the same photograph as WebP at an equivalent perceived quality and you’re usually looking at 120 KB to 170 KB. On one image, that gap is modest. Across a page that loads eight or ten product photos simultaneously, you’ve cut anything from 600 KB to over a megabyte of transfer before a visitor has scrolled past the fold.
On a slower mobile connection, that difference is felt, not just measured. Google’s own Lighthouse tool flags uncompressed or format-inefficient images as one of the highest-impact fixes precisely because the cumulative weight adds up so quickly across a typical page load.
WebP earns its keep most with photographs and images that contain a lot of fine detail and gradient tones. Flat graphics with hard edges and solid blocks of colour see a smaller gap, sometimes barely noticeable. So the real-world saving on any given page depends on what images are on it, which is why the optimisation settings that matter most are always image-type-specific rather than a single blanket rule.
How WordPress Handles Format Conversion
What core does natively
Since WordPress 5.8, the platform has included native WebP support, meaning it accepts WebP uploads and generates WebP thumbnail sizes the same way it handles JPEG or PNG. What it does not do is automatically convert your existing JPEG library into WebP files on upload. If you drag a JPEG into the media library, it stays a JPEG. WordPress core registers the format and processes it; the conversion step is entirely your responsibility.
This catches a lot of people out, particularly those who assume upgrading WordPress itself is enough to start serving faster images.
Browser compatibility is handled at the server level, not by WordPress core. Apache or Nginx can be configured to serve a WebP file when a matching one exists and the browser sends an Accept, image/webp header, but WordPress itself has no built-in mechanism to detect browser support and swap formats on the fly.
What plugins add
Plugins like Imagify, ShortPixel and Smush fill the gap by converting images to WebP at the point of upload, storing both the original and the converted file, then using either a rewrite rule or a JavaScript-based swap to serve the right format per browser. For anyone working through WordPress image optimisation settings, the plugin layer is where most of the real format-switching control sits.
Browser Support and Why It Stopped Being a Problem
For years the standard objection to WebP was Safari. Apple was late to support it, which meant a chunk of real traffic, particularly on iPhones and Macs, would hit a broken image if you served WebP without a fallback. That concern made sense at the time. Safari added full WebP support back in version 14, and given how aggressively Apple pushes iOS updates, the vast majority of Safari users have been on a compatible version for quite some time now. Chrome, Firefox and Edge supported WebP much earlier. Across the browsers your visitors are using, WebP coverage is about as close to universal as web standards get.
The old conditional logic, serving JPEG to Safari and WebP to everyone else, is mostly dead weight now.
There is one situation where a JPEG fallback still has a purpose. If your audience skews toward older embedded browsers, certain smart-TV web views, or legacy enterprise environments where software updates lag by years, a small percentage of users may still miss WebP. Plugins that handle WordPress image optimisation settings often generate both formats automatically and serve the right one via the srcset attribute or a <picture> element, so you get WebP for everyone who can use it and JPEG for the rare edge case, with no manual work involved. For most sites, that automated approach is the right call rather than ditching WebP to play it safe.
Where JPEG Still Wins
Photography portfolios with strict colour-fidelity requirements are one area where JPEG keeps a genuine foothold. High-end retouching studios and commercial photographers often supply finished assets as sRGB JPEGs, colour-profiled and signed off by the client. Converting those to WebP inside WordPress can shift saturation subtly, particularly on wide-gamut displays, and that matters when a client is comparing a screen proof to a physical print.
The same logic applies to editorial workflows where the client supplies and reuses their own image library. If a magazine publisher drops the same JPEG into WordPress, their CMS, and their print pipeline, introducing a WebP conversion mid-flow creates version-control headaches that no page speed gain justifies.
Email is the other clear case. Images linked from a WordPress media library into HTML email campaigns need to be JPEG or PNG. WebP support in email clients is patchy at best, and a broken image in a newsletter is a worse outcome than a slightly heavier file.
Third-party gallery embeds follow the same pattern. If a platform like Flickr or a licensed stock provider serves the image from its own CDN, the image optimisation settings that actually matter are on their infrastructure, not yours. You have no control over format, and trying to proxy or re-serve those assets just to get WebP introduces more complexity than it removes.
The Conversion Settings That Actually Matter
Most people batch-convert their media library, see smaller file sizes, and assume the job is done. The settings behind that conversion decide whether you’ve improved anything at all.
Quality, encoding mode, and chroma
The quality slider is the first place things go wrong. WebP at quality 80 is not the same as JPEG at quality 80. WebP’s compression is more efficient, so you can often drop to 75 or even 70 and see no perceptible loss on standard photography. Go below 65, though, and you start to lose fine edge detail, particularly in images with text, thin lines, or fabric texture.
The format also gives you a choice between lossy and lossless encoding. Lossy handles photographs well. Lossless is intended for graphics with flat colour, logos, and illustrations where pixel-perfect accuracy matters. Batch-converting a whole library to lossless WebP will produce files larger than the JPEGs you started with, which defeats the purpose entirely.
Chroma subsampling is a separate consideration. Most lossy WebP encoding reduces colour information independently of luminance, which is fine for most web images but can affect product shots where accurate colour is the whole point. If your client sells paint or fabric, test a handful of images manually before you commit to bulk settings.
Stripping metadata
Camera EXIF data, colour profiles, and GPS coordinates can add anywhere from a few kilobytes to over 30 KB per image. Plugins that handle WordPress image optimisation settings will usually offer a strip-metadata toggle. Turn it on. The colour profile is the one exception, preserve it if colour accuracy is critical, but for general web use, stripped files load faster and hand nothing personal to anyone scraping your site.
Choosing the Right Approach for Your WordPress Site
The decision comes down to where in your stack you want the conversion to happen.
Converting on upload, using a plugin that rewrites the file as WebP the moment it lands in your media library, is the simplest path for most sites. It handles new images automatically, requires no server configuration, and works on shared hosting where you have little control over the environment. The catch is your existing JPEG library sits untouched until you run a bulk reprocess, which on a site with several hundred images can take a while and occasionally stalls partway through.
Server-level conversion via an image CDN or a module like on-the-fly WebP delivery configured through your image optimisation settings is more reliable at scale, because it serves the right format per browser without touching the originals at all.
For an existing JPEG library, the pragmatic move is to bulk-reprocess through your chosen plugin, then spot-check a handful of the heaviest images in PageSpeed Insights rather than just comparing raw file sizes in the media library. Raw file size is not the metric that matters most. What you are watching is Largest Contentful Paint, because a hero image that shaves 40 KB off its file size but still loads late due to poor prioritisation will not move your LCP score at all. Fix the format, then check the timing.