Left: the percentage of bytes WebP saves against JPEG at the same quality number, peaking at 43.66 percent at quality 75 and falling away at both ends. Right: mean SSIM at the same quality number, where the WebP curve sits under the JPEG curve from quality 70 upward. The two charts together are the argument of this page: the saving on the left is partly paid for on the right. Charts generated from the measurement run described below.
Everyone quotes a WebP saving of about 30 to 40 percent. That number is real and it is measured the wrong way, because the quality slider does not mean the same thing in the two encoders. Score both at equal SSIM instead and the saving halves, one file gets bigger, and the quality number you need moves for every image.
Every guide that mentions WebP quotes the same figure. Around 30 percent smaller than JPEG, sometimes 25, sometimes 35, and on this run at quality 75 it is 43.66 percent.
That number is not made up. It is also measured in a way that quietly stacks the deck, and the honest version of it is roughly half as large.
Both encoders take a number between 1 and 100 and both call it quality. The two numbers are not the same number.
JPEG quality selects a quantisation table scale. WebP quality drives an entirely different set of decisions inside a codec built on intra frame video prediction. Nothing anywhere in either specification says that quality 80 in one has to produce the same visual result as quality 80 in the other, and this run says it does not.
So a comparison at equal quality numbers is not a comparison at equal quality. It is a comparison of two arbitrary settings that happen to share a scale.
Eight 1024 pixel PNGs from this gallery. Each encoded as JPEG with optimize on and as WebP with method 6, the slowest and best of the WebP effort settings, at quality 50, 60, 70, 75, 80, 85, 90 and 95.
Every output is decoded again and scored against the original with SSIM over 11 by 11 Gaussian windows, sigma 1.5, on the luma channel. That is the Wang et al. 2004 formulation rather than a single global figure, which matters: a global SSIM on images like these sits above 0.998 for everything and cannot separate any of it.
Total bytes across the eight files at each quality, with both encoders set to the same number.
| Quality | JPEG bytes | WebP bytes | WebP smaller by | JPEG SSIM | WebP SSIM |
|---|---|---|---|---|---|
| 50 | 628,531 | 389,260 | 38.07% | 0.96111 | 0.95824 |
| 60 | 715,206 | 438,366 | 38.71% | 0.96667 | 0.96287 |
| 70 | 848,265 | 492,454 | 41.95% | 0.97287 | 0.96684 |
| 75 | 932,057 | 525,084 | 43.66% | 0.97609 | 0.96906 |
| 80 | 1,064,191 | 634,622 | 40.37% | 0.97969 | 0.97456 |
| 85 | 1,249,938 | 793,028 | 36.55% | 0.98349 | 0.97968 |
| 90 | 1,576,989 | 1,076,820 | 31.72% | 0.98784 | 0.98522 |
| 95 | 2,287,798 | 1,655,716 | 27.63% | 0.99286 | 0.99024 |
There is the marketing figure, and it is real: between 27.63 and 43.66 percent across the whole range, peaking at quality 75.
Now read the last two columns. The WebP SSIM is lower than the JPEG SSIM at every single quality. Not by much, and at quality 50 and 60 the gap is small enough to argue about, but from 70 upward it is consistent and it grows. At quality 75 the gap is 0.00703, which in SSIM terms on images this clean is not a rounding error.
So part of that 43.66 percent is compression and part of it is just a lower quality image. The table cannot tell you which part is which. That takes a second run.
Here is the fair version. For each file, encode it as JPEG at quality 85, measure the SSIM that produced, then search WebP quality from 30 upward and take the first WebP quality that reaches or beats that same SSIM. Same measured quality, both files, then compare bytes.
| File | JPEG q85 bytes | Target SSIM | WebP quality needed | WebP bytes | Saving |
|---|---|---|---|---|---|
| 00006 | 154,504 | 0.98613 | 90 | 120,548 | 21.98% |
| 00010 | 149,355 | 0.98474 | 90 | 117,636 | 21.24% |
| 00012 | 183,409 | 0.97840 | 88 | 147,838 | 19.39% |
| 00015 | 166,975 | 0.98443 | 89 | 132,826 | 20.45% |
| 00022 | 154,703 | 0.97954 | 88 | 129,014 | 16.61% |
| 00027 | 152,264 | 0.98461 | 89 | 116,862 | 23.25% |
| 00029 | 85,951 | 0.98926 | 94 | 91,284 | -6.20% |
| 00032 | 202,777 | 0.98083 | 87 | 159,458 | 21.36% |
| Total | 1,249,938 | 1,015,466 | 18.76% |
The saving at quality 85 goes from 36.55 percent to 18.76 percent the moment you make the two files actually equivalent. Half of the headline number was never compression. It was a quieter image.
The quality number never matches. Reaching JPEG quality 85 took WebP quality 87 to 94, and it was a different number on every single file. There is no fixed offset you can memorise. If you are converting a library and you set WebP to the JPEG number you were using, you are shipping worse images than you think.
One file got bigger. File 00029 needed WebP quality 94 to match, and at 94 it was 6.20 percent larger than the JPEG. That is one in eight, and it was the smallest and cleanest file in the set at 85,951 bytes, the one with the least texture for the codec to work on. WebP is not universally smaller. It is smaller on busy images and it can lose on simple ones.
The real range is 16.61 to 23.25 percent across the seven files it did win on. That is still a genuinely good result and it is worth doing. It is just not 40 percent.
Nobody is lying about this. The 30 to 40 percent figure comes out of any test that sets both encoders to the same number, and that is the obvious way to run the test. It is even the way most tooling defaults, so it is what people see when they convert a folder and look at the size.
The reason it holds up is that the SSIM cost is invisible on a screen. A gap of 0.007 in windowed SSIM is not something anybody notices on a photograph at normal viewing size, so the smaller file looks identical and the number gets repeated.
Which is fine, as long as you know that is the trade you made. If your quality target is whatever WebP does at 80, take the 40 percent. If your quality target is the same as the JPEG I am replacing, the number is 19 percent and you need to raise the quality setting by roughly 3 to 9 points to get there.
Convert, but raise the number. On this set, WebP quality 90 cleared JPEG quality 85 on every file except the one it could not win at all. A blanket rule of JPEG quality plus 5 gets you most of the way and errs on the safe side.
Check the small files. If a source JPEG is already under about 100 KB at your target quality, run both and keep the smaller one. It will not always be the WebP.
Use method 6. Every WebP number on this page was encoded at the slowest effort setting. Faster settings give up some of an already halved advantage.
If you benchmark it yourself, match the metric and not the slider. That is the whole article. Two encoders sharing a number between 1 and 100 does not make that number mean the same thing twice.