WebP vs JPG (and PNG)

WebP vs JPG comes down to one rule: WebP wins on file size and features for anything you publish on the web, and JPG wins on reaching the places WebP still cannot go. Lossy WebP runs 25 to 34% smaller than a JPEG at the same quality, and it also carries transparency and animation that JPG has never had.

I run all three formats through the engine behind this tool every day, and the size gap is not close once you actually measure it instead of quoting a benchmark. This page puts WebP against JPG and PNG on the same real files: what each keeps and throws away, the byte counts I measured myself, where WebP still gets bounced, and which one to pick for the file in front of you. For the wider story on both modern formats, see WebP and AVIF, the modern formats.

How do WebP, JPG, and PNG compare at a glance?

WebP beats both older formats on compression and on features; JPG and PNG each still win on one thing, JPG on universal photo compatibility, PNG on universal lossless compatibility. Put webp vs jpg vs png side by side and the pattern is consistent: WebP does the jobs of both, JPG and PNG do one job each but reach everywhere.

WebP's compression numbers come from Google's own study, which measured lossy WebP at 25 to 34% smaller than JPEG at an equivalent structural-similarity score, and lossless WebP at 26% smaller than PNG (Google Developers, WebP). Browser reference data lists the same trait split: WebP as the smaller modern format with JPG and PNG holding the deeper historical support (MDN, Image file types).

WebP vs JPG on the same file: what I measured

WebP vs JPG stops being an argument the moment you weigh the same file twice. I took the 497 KB JPEG this site uses in its homepage demo and re-encoded it to WebP at quality 80 on the same engine. It came back at 214 KB, which is 56.9% smaller, with no change I can see at normal zoom.

That is one file, so here is the shape across a few more. Every row below is the same source encoded to each format at quality 80, the default this tool treats as visually lossless for photographs.

The two demo-photo numbers are exact, measured on the file. The phone-photo row is the typical result for a straight-from-the-camera photo: a 4.5 MB original lands near 900 KB as JPEG, and the WebP of the same original comes back roughly a third smaller again, in line with the 25 to 34% Google measured. If you want your own number instead of mine, you can re-encode a JPG or PNG to WebP and read the byte count off your own file.

How much smaller is WebP than JPG, really?

Lossy WebP is 25 to 34% smaller than a JPEG at the same visual quality, and lossless WebP is about 26% smaller than a PNG, both from Google's published measurements rather than marketing rounding (Google Developers, WebP). Browser-reference documentation gives the same photo figure as an average of 25 to 35%, so this is not a single vendor's number, it is the consensus range you can plan around.

Where the saving comes from

WebP earns the gap with a smarter lossy method than JPEG's, plus a lossless mode JPEG does not have at all. JPEG splits an image into 8 by 8 blocks and throws away high-frequency detail your eye barely tracks; WebP does the same job with block prediction borrowed from video encoding, guessing each block from its neighbors and storing only the difference. Fewer bytes describe the same picture, which is why the WebP lands smaller at a matched quality.

For a normal photo, that means a WebP holds the same visible detail as the JPEG while writing fewer bytes to disk. The saving compounds across a page: swap forty JPEGs for WebP on a gallery and you can cut a megabyte or two off the total page weight without touching how any single image looks. On a site judged partly on load speed, that page-weight cut is the whole reason teams bother switching formats at all.

When WebP does not win

WebP does not have to win on every single file, and it does not. Converting a file that has already lost quality, a low-quality JPEG resaved as lossless WebP, or a very low-color PNG resaved as lossy WebP, can come out larger than the original (Google WebP FAQ). The rule holds for real photos and graphics straight from the source; for an already-squeezed file, weigh it before you trust the average.

Does WebP support transparency and animation the way PNG and GIF do?

Yes to both, and that is the feature half of why WebP replaces two formats at once. WebP carries an alpha channel in both its lossy and lossless modes, which JPG cannot do in any variant, and it supports animation, which neither JPG nor standard PNG does.

Transparency

PNG's alpha channel is the reason it exists next to JPEG, and WebP matches it without giving up the compression lead. A lossy WebP with transparency typically lands around a third the size of the PNG it replaces, real alpha at a fraction of the bytes. JPG has no alpha at any quality; a JPG copy of a transparent image is not a smaller version of the file, it is a different file with the see-through area filled solid, almost always white. So the transparency comparison is not really WebP against JPG at all, it is WebP against PNG, and there WebP still tends to win on size while keeping the alpha channel intact. If you need a cutout logo on a colored background, JPG is the wrong tool, and WebP does the PNG job for fewer bytes.

Animation

Animated GIF is stuck at 256 colors per frame with no true transparency. Animated WebP carries full color depth and real alpha, and usually comes in smaller than the same clip as a GIF. PNG's animated variant, APNG, exists but never reached wide tooling support, so most sites that want an animated still-image format reach for WebP, not APNG. The practical read: if you are replacing a heavy animated GIF on a web page, WebP is the drop-in that cuts the bytes and keeps the color, and it is one of the clearest wins the format has over both older options at once.

Will a WebP file open everywhere a JPG or PNG does?

On the browser side, effectively yes now. Every current major browser reads WebP: Chrome since version 32, Firefox since 65, Edge since 18, and Safari since 16.0 after years of partial support (caniuse, WebP browser support). The gap that used to justify skipping WebP is closed for anyone visiting a website.

Off the browser is where JPG and PNG still win outright. Older office software, some print prepress workflows, and a real slice of upload forms reject WebP by extension or MIME type no matter what the visiting browser could show. This is why MDN still recommends shipping WebP with a JPEG or PNG fallback in a picture element for broad reach (MDN, Image file types). JPG and PNG's decades of installed base are a genuine advantage WebP has not matched in those corners yet.

Does renaming a JPG to .webp convert it?

No, and this is the trap that wastes the most time. A file's format lives in the bytes inside it, not in the three letters after the dot. Renaming photo.jpg to photo.webp gives you a JPEG with a lying extension: the header still says JPEG, and any careful program reads that header, not the name, so the file either opens as the JPEG it always was or throws an error for not being a real WebP.

Real conversion re-encodes the pixels through a WebP encoder, which is what produces the smaller file in the first place. The rename does zero of that work, so it also saves zero bytes. If you have been told to change the extension to shrink an image, that advice is wrong; the file is exactly as big as it was. The honest path is to run it through an actual encoder, which is what the convert a JPG to WebP guide walks through step by step.

When should you still use JPG or PNG?

Reach for JPG or PNG whenever the destination is not a web page you control: an email attachment, a document, an upload form that names its accepted formats, or older software you cannot update. Converting a file to WebP changes what you are sending, not what the receiving system accepts.

A resume upload form that lists JPG or PNG only will bounce a WebP even though it is the better-compressed image, and prepress software built before WebP will not open one either. The fix is the same dropdown in either direction: choose WebP as the output when you publish to the web, and choose JPG or PNG when you hand the file to someone else's system. The engine runs the same either way, so matching the format to the destination costs nothing but a different choice. This is also the honest answer to webp or jpg for photos: WebP for photos on your own pages, JPG for photos leaving them.

I hold my own tool to the same rule. This site's compressor will happily hand you a WebP, but if your file is headed for an inbox or a print shop, the right move is to pick JPG on the way out, not to send a WebP that gets rejected on the far end.

How do you switch a site from JPG to WebP without breaking anything?

Convert the files, serve WebP with a JPEG fallback, and keep the originals. The switch is safe when the browser that cannot read WebP still gets a working image, and modern markup does exactly that.

Convert in batches, keep the originals

Run your existing JPGs and PNGs through a real encoder and save the WebP copies alongside the originals, do not delete the sources. You will still want the JPG or PNG for the destinations that reject WebP, and re-encoding from an original always beats re-encoding from a copy that has already lost quality. A batch tool matters here because a real site has hundreds of images, not three.

Serve WebP with a fallback

The picture element lets the browser choose: it tries the WebP source first and falls back to the JPEG if it cannot read it. That is the fallback pattern the browser-format documentation recommends, and it means an old browser or an offline reader never sees a broken image, only the JPEG. You get the smaller file for everyone who can take it and a guaranteed image for everyone who cannot.

Check the size before and after

Weigh a handful of pages after the switch. The point of the exercise is the byte count, so confirm the WebP versions are actually smaller for your images, since a few already-compressed files may not shrink. Measure, do not assume, and roll back any file that came out larger.

Which format should you actually pick?

Match the format to where the file is going, not to which one compresses best in the abstract: WebP for anything you publish on the web, JPG or PNG for anything leaving it.

If your source files are already JPG or PNG and the destination is the web, the one-step move is to convert them and keep the originals. For the format one rung newer again, AVIF against WebP covers where the next generation pulls ahead and where it is not worth the slower encode yet. If you are still deciding what WebP even is before choosing it, what is WebP is the plain-language version.