Converting WebP Back to JPEG Costs About 8 Quality Points
On 320 photos, a WebP round trip scored 8.2 points below a plain JPEG re-encode. All 320 got worse, and the resulting file came out smaller too.
Every "webp to jpg" page explains how to convert. None of them say what you lose.
That question has a clean form. Take one original JPEG and send it down two paths. In the first, re-encode it to JPEG at quality 90. In the second, encode it to WebP at 90, decode that, and then encode the result to JPEG at 90. Both paths end in the same format, at the same quality, through the same encoder. The only difference is the WebP step in the middle.
Whatever separates the two scores is the cost of that step.
What we ran
320 JPEGs, up to six from each folder of a collection. Each was scaled to 768 px on the long edge and saved as a PNG, which is the reference everything is scored against.
Then the two paths, with the control and the experiment sharing the reference and the final quality setting. Scoring is SSIMULACRA2.
One thing to know about the encoders: this used Pillow's libwebp and libjpeg, not the encoders this site runs. So the numbers describe the cost of the format, not the behaviour of any particular tool. That is the same setup as our chroma subsampling study, so the two are directly comparable.
The numbers
- Direct re-encode to JPEG: mean score 87.84
- WebP, then back to JPEG: mean score 79.64
- Difference: 8.20 points, median 7.87
- Worse on 320 of 320 images, every one by more than a point
- Sizes: 261.0 KB as JPEG, 175.1 KB as WebP (−32.9%), 236.3 KB as the returned JPEG (−9.4%)
Read the last two lines together, because they are the part that misleads people.
The trap in that smaller file
The JPEG that came back through WebP is 9.4% smaller than the one that never touched WebP. If you only watched file size, that looks like a win.
It is not. It is smaller because WebP already threw detail away. Your JPEG is smaller for the same reason a lower quality setting produces a smaller file: there is less in it.
This is the general failure of judging a conversion by its output size. A file that is smaller and measurably worse is not a saving.
Eight points is a lot
For scale: dropping chroma subsampling from 4:4:4 to 4:2:0 costs about 5 points on the same metric. A WebP round trip costs 8. So the format detour does more damage than the setting every compressor is criticised for changing silently.
That sounds like an argument against WebP. It is not. It is an argument against converting back.
What to actually do
- If you are serving the image yourself, WebP at 32.9% smaller for the same nominal quality is a real win. Keep it. Our own format comparison has the details.
- If you still have the original, convert from that, not from the WebP. The original is the only copy that has not already been through one lossy pass.
- If all you have is a WebP, converting it is still fine, and the result will still look like the WebP. But expect a file that is around 9% smaller and a little worse than you hoped, and do not then compress it again.
The expensive mistake is converting to WebP, deciding you need JPEG after all, and converting back from the WebP because it is the copy you have open.
Caveats
One collection, mostly already-compressed JPEGs. The sources had already been through one lossy pass before this test started, so the numbers are the cost of the second and third, not the first.
Quality 90 throughout. The gap will move at other settings, and we did not test them.
Pillow's WebP encoder is not Google's reference encoder and is not the one your browser uses. A different encoder would shift the absolute numbers, though the shape of the result, a large cost on every file, seems unlikely to be an artefact of the implementation.
768 px images. Larger images have more detail to lose.
And the usual caveat: SSIMULACRA2 correlates well with human judgement on average.
Reproducing it
The script is tools/measure-webp-roundtrip.py. It needs Pillow and ssimulacra2 on the path, takes about seven minutes for 320 images, and writes per-image numbers to JSON.
If you run it and get a materially different result, the address is on the about page. All four of our other measurements are collected on one summary page.