The short answer
If the image is going to be displayed in a browser, use WebP. If the image is going to be handed to a person as a file, use JPG.
That single distinction resolves most of the argument. WebP is meaningfully more efficient and every current browser reads it. Outside the browser, support is patchy in ways that produce confusing failures — an upload form that rejects the file without saying why, a print service that will not accept it, an older desktop application that shows nothing.
The size advantage is real and consistent: 25 to 35 percent smaller than JPEG at visually matched quality, with the gap widening on images containing large smooth areas and narrowing on busy, noisy ones.
Why WebP compresses better
JPEG was finalised in 1992. It splits the image into 8x8 blocks, converts each into the frequency domain, and quantises the high-frequency coefficients. That was a strong design and it has aged well, but it predates three decades of compression research.
WebP borrows its lossy mode from the VP8 video codec, which brings tools JPEG never had. It predicts each block from already-decoded neighbouring blocks and encodes only the difference, so a smooth gradient costs almost nothing. It uses arithmetic coding rather than Huffman, which is closer to the theoretical limit. And it uses larger, adaptive transform choices instead of a fixed 8x8 grid.
The practical consequence is that WebP is dramatically better at exactly the content JPEG handles worst: skies, studio backdrops, out-of-focus backgrounds, and any wide area of slowly changing colour. Those are where JPEG produces visible banding and where WebP does not.
Numbers from the same source image
A 12-megapixel photo of a landscape, exported from the same original at visually matched quality:
- JPEG quality 80: 1.4 MB
- WebP quality 80: 950 KB (32% smaller)
- JPEG quality 60: 700 KB, visible banding in the sky
- WebP quality 60: 480 KB, no visible banding
- PNG (lossless, for reference): 14 MB
Where WebP actually wins you something
Page weight is the main one. Images are typically the largest thing a page downloads, so a third off every photo is a direct cut to total transfer and to Largest Contentful Paint. On a gallery of twenty images at 400 KB each, moving to WebP removes roughly 2.6 MB from the page.
Lighthouse and PageSpeed Insights flag this explicitly with a serve images in next-gen formats recommendation, and WebP is what they mean. The format is not itself a ranking factor, but the speed improvement it produces feeds into metrics that are.
WebP also has an alpha channel, which JPEG does not. That means one format can serve both your photographs and your logos, where previously you needed JPEG for one and PNG for the other. A transparent WebP is typically 25 to 35 percent smaller than the equivalent PNG.
Where JPG is still correct
Anything a human will receive as a file. Email attachments, files shared over messaging apps, images sent to a client or a printer. You do not control what software they will open it in, and JPEG is the only format you can be certain works everywhere.
Upload forms with fixed extension whitelists. Job applications, government portals, exam boards, and older content management systems frequently accept only jpg, jpeg, and png. This is the single most common source of confused WebP rejections.
Print workflows. Many print services have not added WebP, and some that accept it convert it back to JPEG internally anyway, which means an extra generation of loss for no benefit.
Camera and archive originals. If the file is your master copy, keep it in whatever the camera produced. Re-encoding to WebP to save space on an archive trades irreplaceable detail for disk you can buy more of.
The double-encoding trap
Converting an existing JPEG to WebP means encoding an already-lossy file a second time. Every generation of lossy encoding discards something, and the second pass is working on an image whose easy redundancy has already been removed.
At quality 90 the second pass is invisible in normal viewing, which is why conversion tools generally default high. At quality 70 you may start to see softness in areas the original JPEG had already worked hard on — fine foliage, hair, fabric texture.
If you still have the camera original or an unflattened export, converting that directly to WebP gives a better result than converting the JPEG. One generation of loss instead of two. This matters most for images that will be looked at closely and barely at all for thumbnails.
Serving both
You do not have to choose site-wide. The picture element lets a browser take WebP while anything that cannot read it falls back to JPEG automatically, with no scripting and no user-agent sniffing.
Most content management systems and image hosts now do this for you, generating both formats at upload and negotiating per request. If yours does, the WebP-versus-JPG decision has already been made on your behalf and correctly.
The remaining decision is what you hand to people directly, and there the answer stays JPG until the software ecosystem outside browsers catches up.
AVIF is the next argument, not this one
AVIF compresses roughly 20 to 30 percent better than WebP again, derived from the AV1 video codec the same way WebP was derived from VP8. On paper it wins outright.
Support is the problem, and it is the same problem WebP had a decade ago rather than a worse one. Browsers are largely there. Everything outside the browser is not, and encoding is considerably slower — noticeably so on large batches, which matters if you are converting a library rather than a handful of hero images.
The sensible position today is WebP as the default with a JPEG fallback, and AVIF added on top for the few images where page weight genuinely dominates, such as a full-bleed hero. Waiting for AVIF before doing anything is the one clearly wrong choice, because the WebP saving is available right now.
Common mistakes when switching
Converting the entire media library at low quality to maximise the saving. The double-encode compounds, and you have replaced originals you cannot get back. Convert at 85 to 90 and keep the sources.
Assuming the format fixes an oversized image. A 4000-pixel photo displayed in a 600-pixel column is wasteful in any format. Resize first; the format choice is worth 30 percent, the resize is worth 90.
Shipping WebP with no fallback in a context that is not a browser — an email template, for instance, where several major clients still render nothing at all.
Renaming a .webp file to .jpg. The extension is not the format. Software that reads the file header will still see WebP, and software that trusts the extension will fail more confusingly than before.
Frequently asked questions
Is WebP better than JPEG?
For browser display, yes — 25 to 35 percent smaller at matched visual quality. Outside the browser, JPEG's universal support usually matters more than the size saving.
Do all browsers support WebP?
Yes, including Safari, and have for years. The support gaps are in desktop software, print services, and upload forms rather than browsers.
Does WebP help SEO?
Indirectly. Smaller images improve page speed and Largest Contentful Paint, which are ranking inputs. The format itself is not a ranking factor.
Will converting my JPGs to WebP lose quality?
A little, because you are encoding an already-lossy file again. At quality 90 the loss is invisible. Convert the original rather than the JPEG export if you still have it.
Can WebP do transparency?
Yes, a full 8-bit alpha channel, and a transparent WebP is typically 25 to 35 percent smaller than the equivalent PNG.
Why did a website reject my WebP upload?
Almost always a fixed extension whitelist rather than anything wrong with the file. Convert to JPG or PNG and it will go through.