The answer, measured
On photographs, reaching the same measured quality costs WebP about a third fewer bytes than JPEG: 32% fewer at SSIM 0.95, 25% at 0.90, 42% at 0.97. On graphics and interface screenshots the gap is wider still. Those are the honest numbers; the interesting part is why so many comparisons report something much smaller, which this page shows happening in its own data.
| Target SSIM | JPEG, bits per pixel | WebP, bits per pixel | WebP saving | Images reaching it |
|---|---|---|---|---|
| 0.90 | 0.78 | 0.59 | 25% | 23/24 |
| 0.95 | 1.56 | 1.05 | 32% | 24/24 |
| 0.97 | 2.65 | 1.52 | 42% | 24/24 |
Each row holds the target quality fixed and asks what each format pays to reach it, interpolated from that image’s own measured curve; the last column says how many corpus images bracket the target. There is no row for SSIM 0.99 because no photograph in the corpus reaches it from either encoder by quality 95: at the very top, both formats run out of road before perfection.
Same number, different meanings
Most casual comparisons encode both formats at the same setting and compare sizes. Here is what that produces on this corpus:
| Category | JPEG bpp | JPEG SSIM | WebP bpp | WebP SSIM |
|---|---|---|---|---|
| Photographs | 1.07 | 0.9315 | 1.00 | 0.9466 |
| Interface | 0.44 | 0.9923 | 0.31 | 0.9977 |
| Text and tables | 0.43 | 0.9875 | 0.36 | 0.9978 |
| Graphics | 0.26 | 0.9970 | 0.13 | 0.9986 |
Read the photograph row and WebP looks a modest 7% smaller. But look at the SSIM columns: at the same “75”, the WebP file is also measurably closer to the original. The two encoders’ dials are not the same instrument, so holding the number equal holds nothing equal; the WebP advantage has simply been spent on quality instead of size. Match the quality instead, as the first table does, and the saving triples. When two benchmarks disagree about WebP, this is usually the whole disagreement.
The whole curve at once
The rate-distortion view compresses every setting into one picture: at any height you care to draw a line, WebP crosses it first. The gap is widest in the middle of the range, exactly where web images live.
Where WebP wins biggest
Photographs are WebP’s smallest win. At quality 75, our graphics images cost 0.13 bits per pixel in WebP against 0.26 in JPEG, half the size and still higher SSIM; and for near-perfect targets that JPEG’s block transform struggles to hit at all on hard edges, SSIM 0.99 on interface, text and graphics, WebP gets there with 54% to 68% fewer bits. If the image is a chart, a diagram or a screenshot and it must be lossy, WebP is not an optimisation, it is a category difference. (If it can be lossless, PNG remains the right answer, and its own measured numbers are on the quality-settings page.)
When JPEG is still the right call
Where the receiver is unknown, JPEG’s thirty-year head start still counts: ancient software, embedded systems, print workflows and picky upload forms all read it. Encoding speed differs too, though not simply: at quality 75 our WebP encoder spent about a third more time per megapixel than mozjpeg, while at 95 it was the faster of the two. And a photograph that will be edited again belongs in neither format; recompress last, once, from the original.
How these numbers were made
- Encoders: mozjpeg via @jsquash/jpeg 1.6.0; libwebp via @jsquash/webp 1.5.0 (portable, non-SIMD build); oxipng via @jsquash/oxipng 2.3.0. These are the exact WebAssembly binaries the tools on this site run in your browser, not a different build of the same library.
- Corpus: 24 photographs (the Kodak PhotoCD test set), 2 interface screenshots, 1 text-and-table page and 2 graphics, all fixed and hash-pinned.
- Quality score: SSIM and PSNR on BT.601 luma, 11 by 11 gaussian window, computed by our own tested implementation.
- Timings: single-threaded on an Intel Core i7-10510U CPU @ 1.80GHz, single thread, Node v24.13.0. Your device will differ; the shape of the curves is the finding, not the milliseconds.
- Measured: 2026-09-02. The full per-image data is free to download as JSON or CSV, CC BY 4.0.
The same caveat the quality-settings page carries applies here: SSIM is computed on luma, so colour bleeding is under-counted, and it is a metric, not a pair of eyes. The compressor on this site shows you your own image at any setting, which beats both.