Back in 2021 I had a WooCommerce client in Birmingham, a homewares shop with about 4,000 product photos, all massive JPEGs shot on a Canon DSLR and uploaded with zero processing. Their largest Contentful Paint was sitting at 7.2 seconds. Brutal. I converted the lot to WebP using Squoosh CLI, re-ran Lighthouse, and got LCP down to 2.8 seconds in a single afternoon. The client cried. Genuinely.
But here's the thing: that same trick would have done very little for a different client I was working with the following month, a photojournalism portfolio site where colour fidelity and print-quality exports actually mattered. WebP was the wrong call there. I used JPEG with aggressive Lightroom export settings instead, and the performance gap was negligible because the images were already properly sized.
So let's talk about this properly. Not "WebP is always better" and not "JPEG is a classic for a reason." The real answer is more situational than either camp admits.
---
What's Actually Different Under the Hood
JPEG has been around since 1992. It uses discrete cosine transform compression, which is brilliant for photographs but starts to fall apart at high compression ratios because it introduces those familiar blocky artefacts. Most web developers know this.
WebP was released by Google in 2010 and uses a predictive coding model borrowed from the VP8 video codec. The short version: it models spatial relationships between pixels more cleverly, which means it can squeeze more quality into fewer bytes. According to Google's own research, WebP lossless images are 26% smaller than PNGs, and lossy WebP is 25-34% smaller than comparable JPEGs at equivalent quality.
Those numbers hold up in practice. Mostly.
Where the gap actually shows up
The 25-34% savings tend to materialise on natural photographs with smooth gradients, product shots on white backgrounds, and lifestyle imagery. The gap shrinks considerably on high-frequency detail: tight fabric textures, dense foliage, architectural patterns with lots of repetition. I've tested this with ImageMagick side-by-side comparisons plenty of times. On certain highly detailed shots, the size difference drops to under 10%, and sometimes WebP even loses at the same quality setting.
---
Browser Support in 2026: Is This Still a Conversation?
Honestly, browser support was the real argument for sticking with JPEG back in 2018. Internet Explorer. Safari being slow to adopt. All of that.
It's gone. Can I Use puts global WebP support at over 97% at this point. Safari added full support in version 14 back in 2020. IE is dead and buried. There's no meaningful audience segment that can't receive a WebP image in 2026.
The only edge case I still encounter is: if you're serving images as email attachments or embedding them in PDF exports generated server-side, some older rendering pipelines choke on WebP. That's it. For everything browser-delivered, the support argument is over.
---
Core Web Vitals: Where Format Choice Actually Moves the Needle
LCP (Largest Contentful Paint) is the Core Web Vitals metric most directly affected by image format. It measures how long it takes for the largest visible element to load. If that element is an image (and it usually is on marketing and e-commerce sites), then format, size, and delivery method all matter enormously.
Here's a practical breakdown of where I've seen format choice make a real difference:
- Hero images: These are almost always the LCP element. If your hero is a 1.2MB JPEG at 1920px wide, converting to WebP at quality 82 will routinely get you to 380-450KB without visible quality loss.
- Product image grids: Lots of small images loading simultaneously. WebP's consistent 25%+ savings compound here. Faster grid = lower total blocking on mobile.
- Blog post inline images: Genuinely low impact. A 200KB JPEG versus a 140KB WebP in the middle of a 3,000-word article isn't moving your LCP.
- Icons and logos: Neither. Use SVG. I have to say this every single time.
- Thumbnails in archive pages: WebP wins here, especially when you're loading 20-30 thumbnails in a grid. That's where byte savings stack up fast.
Seahawk had a fintech project last year where the marketing site had 14 above-the-fold images rotating in a hero carousel. Madness, but the client insisted. Converting all 14 from JPEG to WebP at quality 80 and serving them via Cloudflare CDN dropped their LCP from 4.1 to 2.3 seconds on mobile. The carousel was still a terrible idea, but at least it loaded quickly.
---
The AVIF Question
Every time I write about WebP someone asks about AVIF. Fair.
AVIF is the next step. It's based on the AV1 video codec, produces even smaller files than WebP (often 20-30% smaller again on photographs), and handles HDR content properly. Browser support is now solid for Chrome, Firefox, and Safari. The problem is encoding speed. AVIF is slow to encode, meaningfully slow. Running a batch conversion of 4,000 product images through AVIF on a VPS will take you a long time. WebP is significantly faster to produce.
My current thinking: use WebP as your default delivery format. If you're building a high-traffic site where the extra AVIF compression gains justify the encoding overhead, serve AVIF to browsers that support it with a WebP fallback. The <picture> element with <source type="image/avif"> handles this without any JavaScript.
Don't let AVIF paralysis keep you on JPEG. WebP is the right pragmatic default right now.
---
My Actual Workflow for Choosing a Format
After 9 years and somewhere north of 12,000 sites, this is roughly how I think about it:
- Is it a photograph or photo-realistic image? Start with WebP lossy at quality 80-85. Compare against JPEG at quality 75. Take the smaller one that passes the squint test.
- Is it a graphic, logo, or illustration with flat colours? SVG if possible, PNG if not. WebP lossless is an option but rarely the best one.
- Is it a screenshot with text? PNG. Always PNG. JPEG and WebP both introduce artefacts around text edges that look terrible.
- Is it served via a modern CDN that does format negotiation automatically? If you're on Cloudflare with Polish enabled, or using Cloudinary, or Imgix, then honestly you don't need to worry much. They'll detect the browser and serve the optimal format. Let the tooling handle it.
- Is it a WordPress site? Install ShortPixel or Imagify and configure them to convert on upload. Done. You don't need to manually manage this at all.
A word on quality settings
Quality 80 is not quality 60. I see developers set WebP quality at 60 because "it's still better than JPEG" and then wonder why clients complain about muddy product photos. Do your visual QA properly. I run every format decision through Squoosh in the browser, toggling between original and output with the split-view tool. Takes 3 minutes per image type and saves client arguments.
---
When JPEG is Still the Right Answer
I'll say it plainly because I don't see enough people saying it: JPEG is not obsolete.
If you're building a site where images will be downloaded and re-edited (photography portfolios, stock imagery, press asset libraries), JPEG is still sensible. It's universally supported in every image editing application on Earth. WebP export quality in tools like Photoshop has improved dramatically, but the ecosystem around JPEG for post-processing workflows is simply more mature.
Also, if your images are already well-optimised JPEGs (say, under 100KB for a 800px wide image), the conversion to WebP produces maybe 15-20KB of savings. That's not zero, but it's not worth the engineering time if you're hand-rolling the conversion. Pick your battles.
And if you're printing. Obviously. WebP is a web format. Don't use it for anything that ends up on paper.
---
Practical Tools Worth Knowing
These are the tools I actually use, not a padded list:
- [Squoosh](https://squoosh.app/): Browser-based, no install, brilliant for one-off comparisons and finding the right quality setting before automating anything.
- Squoosh CLI: Batch conversion from the terminal. I use this for project-level migrations.
- ShortPixel: Best WordPress plugin for automated conversion on upload. The lossy setting is sensible out of the box.
- Cloudflare Polish: If you're already on Cloudflare Pro, turn this on. It converts and compresses at the edge automatically. Zero code required.
- Cloudinary: The choice for larger editorial or e-commerce operations where you need format negotiation, responsive sizing, and CDN delivery as a managed service.
- ImageMagick: Command-line conversion for server-side workflows. Slower than Squoosh CLI but more flexible for scripted pipelines.
---
FAQ
Is WebP always smaller than JPEG?
No. I wish people would stop saying this. On highly detailed, high-frequency images (think: macro photography of rough textures, densely detailed architectural shots), the size difference can be negligible or even reversed depending on the encoder settings. Test your specific images rather than assuming.
Do I need to keep the original JPEG if I convert to WebP?
Yes. Always keep your originals. WebP is a delivery format, not an archival format. If you're running a WordPress site with ShortPixel, the plugin keeps the original by default. Don't change that setting.
Will converting to WebP hurt my image SEO?
No. Google indexes WebP images without any issues. Make sure your alt text is descriptive and your file names are sensible. Format has no effect on image search rankings.
What about the `<picture>` element versus just serving WebP directly?
If 97%+ of your users support WebP, serving WebP directly via an <img> tag is fine. The <picture> element with source fallbacks made sense when Safari was the holdout. Now it's mainly useful for the AVIF-with-WebP-fallback pattern I mentioned earlier.
Does image format affect CLS (Cumulative Layout Shift)?
Format itself doesn't. But if you're converting images and not setting explicit width and height attributes (or using aspect-ratio in CSS), you'll get layout shift regardless of format. This is one of the most common mistakes I see when people do bulk format migrations. Fix your dimensions.
---
Format decisions feel small. They're not. I've seen a single afternoon of image optimisation take a site from "failing Core Web Vitals" to "passing" and meaningfully move conversion rates for e-commerce clients. WebP is the right default in 2026 for almost every browser-delivered photograph. But it's a default, not a rule. Know why you're making the choice, test before you automate, and keep your originals.