We Converted 15 Real Images to WebP: Here's What Actually Got Smaller

Every WebP guide repeats the same line: "WebP images are about 25–34% smaller than JPEG." That figure comes from a Google study, and it is fine as far as it goes — but it is an average from one test set, and it never told us what our tool does to real files. So we stopped quoting it and ran our own test. We took 15 images we actually had on hand — photos, screenshots, and logos — pushed each one through the same WebP encoder our converter uses, and weighed every byte before and after.

The short version: the median file shrank by 63%, the whole set went from 6.1 MB to 1.5 MB, and one image got bigger. The averages you read elsewhere hide a lot, and the spread is the interesting part. Here is everything we measured.

How We Tested

We wanted numbers we could stand behind, so the method is deliberately boring and repeatable:

• The images: ten photographs from Unsplash saved at a web-typical 1600 px wide, two of those same photos re-exported as PNG (the mistake we see constantly), and three project logos with transparency. A deliberate mix, not a cherry-picked one.
• The encoder: libwebp — the same library that powers the WebP conversion in our browser tool — at its default quality 80. No resizing; each image was converted at its original dimensions, exactly like dropping it into the tool with the resize box left blank.
• The measurement: raw file size on disk, before and after. "Saved" is simply (original − webp) ÷ original.

One honest caveat up front: a browser's WebP encoder and a server's can differ by a percent or two on any single file, and your source quality matters enormously (a JPEG already crushed to quality 60 has less left to give). Treat these as a realistic guide, not a guarantee. The tool on our homepage shows you the exact figure for your file every time you convert one.

The Full Results

Sorted by image type, then by how much each one shrank. Nothing left out — including the photo that barely moved.

Median 63% • mean 64% • range 35–94% • 15 of 15 images got smaller. All conversions at quality 80, original dimensions.

What the Spread Tells You

Photos saved as PNG are the easy money

The two biggest wins, by a mile, were ordinary photographs that someone had exported as PNG. A 2.1 MB PNG collapsed to 169 KB — a 92% cut — and the visual difference is invisible at normal viewing size. PNG is a lossless format built for graphics with sharp edges and flat color; forcing a million-color photograph through it produces an enormous file that gains you nothing. If you remember one thing from this test: never ship a photograph as a PNG. Re-save it as JPEG or, better, WebP.

Already-JPEG photos still gave up half their weight

This is the case people doubt: "my images are already JPEGs, what's left to squeeze?" Quite a lot. The ten JPEG photos shrank a median of 58%, roughly doubling the headline number you see quoted for WebP. The variation is the honest bit. The flat analytics dashboard, with its big blocks of solid color, gave back 68%. The noisy, high-detail data-center shot — thousands of cables and blinking lights, the kind of texture compressors hate — managed only 35%. Detail and noise are the enemy of compression, in any format.

Logos with transparency convert cleanly

All three logos kept their transparent backgrounds and still dropped 65–79%. That matters because the usual reason people stay on PNG for logos is the alpha channel — and WebP carries it across without complaint. One nuance worth knowing: for very simple flat-color logos, lossless WebP can sometimes beat the lossy quality-80 result. Our browser tool uses lossy mode, which is the right default for the photos that make up most of a page's weight, but it is worth testing both on a pure-vector-style logo.

The One That Got Bigger: Why Quality 100 Backfires

We kept pushing one photo — the 350 KB camera shot — up and down the quality slider to find where the trade lives. The result surprised even us at the top end:

At quality 100, WebP tries to preserve every last artifact already baked into the JPEG — including the JPEG's own compression noise — and the file balloons to nearly double the original. This is exactly the trap the converter warns you about when the result comes out larger. The usable range sits between about 60 and 80: below 60 the artifacts start to show on close inspection, and above 90 you are paying a steep size penalty for quality almost nobody can see. Eighty is a sensible default, which is why it is the one we ship.

Why This Matters for Your LCP

On most pages the Largest Contentful Paint element is an image, and image weight is the single biggest lever on how fast it appears. Take the camera shot: as a 350 KB JPEG over a mid-range mobile connection it is a noticeable wait; at 169 KB it arrives in roughly half the time. Multiply that across a gallery or a long article and you are shaving whole seconds off the load — the kind of change that moves a "needs improvement" LCP into the green. Smaller files are not an abstract nicety; they are the most direct fix for the Core Web Vital that fails most often.

The Honest Caveats

Fifteen images is a sample, not a census. The numbers would shift with a different set — more illustrations would push the median up, more grainy night photography would push it down. The takeaways hold regardless: WebP at quality 80 reliably beats both JPEG and PNG for photographic content, the biggest wins are hiding in mis-saved PNGs, and cranking quality to the maximum is counter-productive. But for the exact saving on the exact file you care about, there is no substitute for converting it and reading the number off the panel.