What the image quality slider actually does
Quality 80 is not "80% as good". Understanding what JPEG discards explains why 80 looks fine, 60 is often fine too, and re-saving is what kills an image.
Quality is not a percentage of anything
The number in a compression dialog is not “keep 80% of the image”. It is an index into a table of quantisation values — how aggressively the encoder rounds off the fine detail it has decided you will not miss.
JPEG works by splitting the image into 8×8 blocks and describing each as a sum of frequency patterns: broad areas of colour are low frequency, sharp edges and texture are high frequency. The eye is far more sensitive to the first than the second. The quality setting decides how coarsely the high-frequency parts get rounded. At high quality they are kept almost exactly; at low quality they are rounded so hard that entire patterns become zero, which is where blocky skies and haloed text come from.
This is why the relationship between quality and file size is nothing like linear. Dropping 100 to 90 often halves the file and changes nothing you can see. Dropping 50 to 40 saves very little and looks noticeably worse.
Where to set it
| Quality | Looks like | Use for |
|---|---|---|
| 95–100 | Indistinguishable from the original, very large file | Archiving; almost never worth it for the web |
| 80–90 | Indistinguishable in normal viewing | The default for anything that matters |
| 65–80 | Slight softening in fine texture | Photographs on a page, thumbnails |
| 50–65 | Visible artefacts around edges and in flat gradients | When a hard size ceiling forces it |
| Below 50 | Obvious blocking and colour banding | Almost nothing |
Start at 80 and go down only if a file size ceiling makes you. The image compressor shows the resulting file size as you move the slider, which turns this from a guess into a decision.
Re-encoding is the real damage
JPEG is lossy, and it is lossy every single time. Open a JPEG, save it again, and the encoder quantises an image that has already been quantised. Do that a few times and edges acquire visible halos and flat areas go blotchy — even at high quality, because each pass rounds off what the previous pass left behind.
This matters practically because every platform re-encodes what you upload. You cannot stop that, but you control what it starts from. Upload something you already compressed to 40 KB and the platform compresses that again. Two lossy passes compound; one does not.
So: always keep the original, edit from it rather than from an export, and compress exactly once, at the end.
When JPEG is the wrong format
JPEG's assumptions are built for photographs — smooth gradients, continuous tone, no hard edges. Give it something else and it fails visibly.
- Screenshots, text, diagrams, line art, logos → PNG. Sharp black-on-white edges are pure high frequency, exactly what JPEG throws away, so text acquires grey fringes. PNG is lossless and usually smaller for this kind of image anyway.
- Anything needing transparency → PNG or WebP. JPEG has no alpha channel; transparency becomes white or black.
- Photographs for the web → WebP if you can. At the same visual quality it is typically 25–35% smaller than JPEG, and every current browser supports it.
The format converter will move between them; it is worth trying the same image both ways and comparing the two file sizes rather than assuming.
Resize before you compress
The largest saving available is almost never the quality slider. It is the dimensions. A 4000-pixel-wide photograph displayed in a 800-pixel-wide column is carrying twenty-five times the pixels it needs, and no quality setting recovers that waste. Halving both dimensions quarters the pixel count.
Order of operations: resize to the size it will actually be shown at, then compress. Doing it the other way compresses pixels you are about to discard.
Why two tools give different results at the same setting
Quality 80 is not a standard. Different encoders use different quantisation tables, different chroma subsampling defaults and different optimisation passes, so quality 80 in one tool is not quality 80 in another. Browser-based tools use whatever encoder your browser ships, so the same page can even produce slightly different output in Chrome and Safari.
The practical consequence is to judge by the result rather than by the number. Look at the output and the file size; the setting that produced them is an implementation detail.