How Far Can You Drop JPEG Quality? Measured Sizes by Quality and Format

"This image is too heavy, I should compress it — but won't lowering the quality ruin it?" That hesitation often ends with someone re-saving at quality 100 and making the file larger than it started. The only way to know what actually happens is to measure. We took a single photograph and re-encoded it through exactly the same path the Image Compressor uses — the browser's canvas — at ten quality steps and three formats, recording the real byte sizes.

How we measured

We used one file: the sample image shipped with this site, a 800×600px JPEG of 39.3 KB (40275 bytes). It is drawn onto a canvas and written out with canvas.toBlob(type, quality); we recorded the size of the resulting Blob as-is. The browser was Chromium. One detail matters throughout: the original is already a JPEG, so every number below is the result of re-encoding a JPEG.

How much does lowering quality actually save?

The quality argument runs from 0 to 1; we show it as a percentage. "vs original" compares against the 39.3 KB source, and "vs JPEG" is the WebP size as a share of the JPEG at the same quality.

Three things stand out.

1. Quality 100 is not "lossless" — it is just bigger

JPEG at quality 100 came to 90.6 KB, which is 230% of the 39.3 KB original — more than double. JPEG remains lossy at 100, so re-encoding an existing JPEG cannot restore detail that was already thrown away; it only spends more bytes describing the artefacts. For reference, writing the same canvas out as a truly lossless PNG gave 136.6 KB, or 347% of the original. PNG is the wrong container for photographs if size matters.

2. Below about quality 80, you stop gaining much

Quality 80 produced 15.5 KB, 39% of the original. Dropping all the way to quality 30 only reached 7.6 KB (19%) — a further saving of just 7.9 KB, while visible damage accelerates. The useful range of the quality dial is largely spent by the time you reach 80.

3. WebP lands around half of JPEG at the same setting

At quality 80, JPEG 15.5 KB versus WebP 7.8 KB — 50%. The ratio stayed near 50% across the whole quality sweep, so simply changing format with the Image Format Converter is worthwhile on its own. Check the destination first, though: some mail clients and older applications still cannot open WebP.

When resizing beats quality

If the image is larger than the size it will be displayed at, changing the dimensions is a more reliable win than touching quality. Scaling the same photo to 400×300px (half the width) before writing it out gave:

Half width at quality 80 is 7.1 KB, 18% of the original — smaller than full size at quality 30 (7.6 KB), and it looks better too: a smaller image reads as simply smaller, whereas blocking artefacts read as damage. Halving the width quarters the pixel count, which is where the saving comes from. The order to work in is Image Resizer first, then Image Compressor if still needed.

Practical rules

• Photos for the web: resize to the display size, then JPEG at about quality 80 — WebP where the audience allows it.
• Logos, diagrams, anything with text: edges smear first, so use 85–90 or PNG. Flat graphics with few colours can be smaller as PNG than as JPEG.
• Already-compressed files: a lower quality setting will still shrink them, but the loss stacks on top of the previous one and cannot be undone. Re-saving at a high quality, on the other hand, can add bytes for nothing — see the table above. Check the dimensions first.
• Email attachments: if you do not know what the recipient can open, JPEG is the safe choice.

The caveat: these numbers hold for these conditions

Everything above describes one photograph re-encoded in Chromium. Image content (flat sky versus fine foliage), the compression history of the original, and the browser's encoder all move the numbers. The shape of the result — 100 grows the file, gains flatten below 80, WebP is roughly half, resizing wins — reproduces easily; the absolute values are worth checking on your own files. The Image Compressor shows the resulting size as you move the quality slider, so you can run this same experiment on your own image.

Frequently asked questions

All figures were measured by re-encoding one sample image bundled with this site (800×600px, 39.3 KB) through Chromium's canvas.toBlob(), as of 2026-07-30. Both the image and the measurement stayed in the browser; nothing was sent to our servers.