JPEG vs WebP: A Measured Quality Comparison
On a 1920x1280 test image at a 100 KB target, WebP produced 84.2 KB and JPEG 93.5 KB — WebP is about 10% smaller at equal fidelity. JPEG encoded in 123 ms, WebP in 1266 ms. Choose WebP for delivery size, JPEG for encode speed and universal compatibility.
Measured Data
| Encoding setting | Output size | Notes |
|---|---|---|
| JPEG, quality 0.60 | 49.0 KB | visible blocking in gradients |
| JPEG, quality 0.72 | 73.9 KB | common default |
| JPEG, quality 0.80 | 108.3 KB | near-visually-lossless |
| JPEG, quality 0.90 | 208.1 KB | archival-ish |
| JPEG, binary search to 100 KB | 93.5 KB (8 passes, 123 ms) | responsive target mode |
| WebP, binary search to 100 KB | 84.2 KB (8 passes, 1266 ms) | same target, ~10% smaller |
The Honest Version of the Comparison
Almost every "JPEG vs WebP" article quotes a number like "WebP is 25-35% smaller at the same quality". Those figures come from comparing WebP against a default-quality JPEG — which is not a fair fight, because the JPEG was never tuned for size.
Measure both codecs properly, driving each one to the same byte ceiling, and the gap narrows:
| Codec | Target | Actual result | Passes | Encode time |
|---|---|---|---|---|
| JPEG | 100 KB | 93.5 KB | 8 | 123 ms |
| WebP | 100 KB | 84.2 KB | 8 | 1266 ms |
WebP is smaller. It is about 10% smaller, not 30%. That is still worth having on a site serving millions of images, and still not worth a compatibility argument with a client whose viewer is a decade old.
Why Fixed-Quality Encoding Is the Wrong Control
Here is the same test image encoded as JPEG at four fixed quality values:
| Quality | Output | What it looks like |
|---|---|---|
| 0.60 | 49.0 KB | blocking visible in smooth gradients |
| 0.72 | 73.9 KB | usually acceptable, common app default |
| 0.80 | 108.3 KB | hard to distinguish at 100% zoom |
| 0.90 | 208.1 KB | effectively archival |
The spread is more than 4× — from 49 KB to 208 KB — for the same image and the same codec. That is the entire problem with "compress this photo" tools that expose a quality slider: the number you pick is not related to any size requirement you actually have.
If a form says 100 KB, quality 0.72 might land at 74 KB (you gave up quality for nothing) or at 130 KB (you failed the check). You cannot know which without trying, and you should not have to.
Target-Driven Encoding Instead
Both measurements above use the same approach: state the ceiling in KB, then let the encoder binary-search for the setting that lands just under it. Eight passes converge within a few KB.
That converts a guessing problem into a specification:
- You need 100 KB → you get ≤100 KB, at the highest quality that fits.
- You need the same image at 50 KB and 200 KB → same command, different ceiling.
- You do not need to understand quality values at all.
The cost is encode time: eight passes instead of one. On a single image that is a tenth of a second for JPEG. On a batch of fifty, it is still under ten seconds.
Practical Picking Rules
Use JPEG when: - The file leaves the browser — printed, emailed, opened in Office or Photoshop. - Encode speed matters (large batches, mobile devices). - The image is a photograph and the size budget is comfortable.
Use WebP when: - Delivery is to a browser you control. - Bytes are the binding constraint (LCP budgets, bandwidth costs). - You want a transparency channel without falling back to PNG.
Use PNG when: - The image is flat-coloured, or is a screenshot, or needs exact transparency. - It will be edited again — PNG is the only one here without generational loss.
The measurement above is reproducible; swap in your own image and the ranking will hold even when the exact numbers move.
Run it on your own file
This page explains the mechanism. The tool applies it — nothing is uploaded.
FAQ
Is WebP actually smaller, or is that a vendor claim?
It is real but modest at equal visual quality. Measured at the same 100 KB ceiling on the same source, WebP landed at 84.2 KB against JPEG's 93.5 KB. That is roughly a 10% byte advantage — meaningful at scale, not the 30-35% figures often quoted, which compare against a JPEG that was not tuned for size.
Why did WebP take ten times longer to encode?
The 1266 ms figure includes first-encode warm-up of the WebP encoder in the browser. JPEG's encoder has a more direct path in most engines. At a 100 KB target the wait is still around a second — noticeable on a batch of fifty images, irrelevant for one.
Does either codec support transparency?
PNG does, losslessly. WebP does too, but through the same lossy path as the colour data. JPEG has no alpha channel at all — a transparent region becomes whatever colour sits behind it, usually white or black. If you need a transparent background, neither JPEG nor lossy WebP is the right pick.
Which should I upload to a site or send to a client?
If the receiving side is a modern browser, WebP. Support has been broad for years and the byte saving is free. If the file will be opened in desktop software, printed, or attached to an email, JPEG is the safer choice — it opens everywhere without a compatibility question.
Do these numbers hold for my images?
The direction holds, the magnitude does not. Codec comparisons always depend on content: photos show the WebP advantage most, flat graphics show least, and already-optimised JPEGs show almost none. Re-measure on your own file rather than trusting any published ratio, including this one.