What image compression actually throws away

What lossy compression really discards, what the quality slider actually scales, and why a target file size can only be measured, not calculated.

Last updated 2026-08-22

Most people picture compression as squeezing a file into a smaller box. Lossy compression does not work like that. It selectively throws information away, and what goes does not come back. Understanding what it discards tells you when to compress, how hard, and why some images stubbornly refuse to shrink.

What gets thrown away

Two things often get conflated. ZIP is lossless: it finds repeated patterns and records them more briefly, and unzipping returns the original bit for bit. JPEG and lossy WebP are lossy: they deliberately discard data in exchange for a far smaller file.

This also explains a common frustration. Zipping photos or video barely helps, because those formats are already the output of lossy compression. What remains is close to random, and ZIP finds no repeated patterns to exploit.

The whole bet behind lossy compression is that human vision has blind spots, and the data covering those spots can go. The next two sections are where the cuts land.

First cut: colour

Human vision is far more sensitive to brightness than to colour. The same subtle shift is visible in luminance and largely invisible in hue. Encoders exploit that directly.

The image is converted from RGB into brightness plus two colour-difference channels, and then only the colour channels have their resolution halved while brightness is kept intact. This is chroma subsampling, usually written 4:2:0, meaning four pixels share one set of colour information.

That single step removes roughly half the data, and on most photographs you cannot see it happen.

It has a cost, and the cost is easy to recognise: red text on a dark background smears, and edges pick up colour fringing. That information lives purely in the colour channels, which is exactly the half that got halved. It is why coloured text in screenshots falls apart so readily while landscapes survive beautifully.

Second cut: detail

The second cut lands on detail, and it is selective.

The encoder divides the image into small blocks (8×8 for JPEG) and runs a frequency transform on each. Afterwards a block is expressed as an overall tone plus a set of coefficients describing how much fine variation it contains. Low frequencies carry broad light and shade; high frequencies carry fine texture.

Then comes the decisive step: quantisation. Each coefficient is divided by a corresponding number from a table and rounded. High-frequency entries are divided by large numbers, so rounding sends many of them straight to zero, taking that detail with them. Long runs of zeros compress extremely well.

This is why an over-compressed JPEG shows visible squares, and why sharp edges pick up a ripple of noise around them. The squares come from the 8×8 grid; the ripple comes from edges that can no longer be reconstructed once their high frequencies are gone.

"Quality 80" is not a percentage

This is the most widely misunderstood number in the field. The quality slider is not "80% of the quality retained", nor a proportion of anything. It is a scaling factor that multiplies the entire quantisation table. Lower numbers make the table values larger, so more coefficients get zeroed.

The consequence matters: every encoder ships a different table. libjpeg at 80 is not mozjpeg at 80, and neither resembles WebP at 80. So "I set 80 in both, why is this one bigger" has no culprit, that number was never comparable across tools.

Why quality presets cannot answer the question

What you usually face is not "I would like quality 80" but "this file must come in under 4 MB or it will not send". No formula connects the two.

That is close to a tenfold spread, and you cannot know it in advance. Picking a quality and hoping is not a strategy when there is a hard ceiling to clear.

How a binary search closes in

With no formula available, measurement is the answer. A binary search works like this:

1. Try the highest quality first. If that already fits, stop, no quality needs sacrificing at all.
2. Otherwise take the midpoint between the lowest and highest quality, encode, and measure.
3. Under the target means there is headroom, so raise the floor. Over it, lower the ceiling.
4. Repeat until the range is narrow enough.

Each round halves the remaining range, so six to ten rounds converge on a close-enough setting. The cost is genuinely encoding six to ten times. On a server that is an expense; in a browser it is a few hundred milliseconds of the visitor's own machine.

If even the lowest quality overshoots, quality was never the problem: there are simply too many pixels. That is when resolution should come down, not before. Exhaust the quality budget first, then touch dimensions: the order makes a real difference to the result.

When compression cannot help

A few situations resist everything, and recognising them early saves time:

• The image is noise. Film grain, high-ISO sensor noise, television static. Every pixel is independent of its neighbours, so there is no pattern to generalise and no redundancy to drop.
• The file was already compressed. What could be discarded went the first time; a second pass mostly adds artefacts while recovering little space.
• The content needs to be lossless. Cut-out assets with transparency, masters headed for further editing, print-bound artwork. None belong in a lossy pipeline.
• Size comes from duration, not quality. The video case: if the bitrate is already at the floor and it still will not fit, that length cannot reach the target at watchable quality. Trim it instead of degrading it further.

Back to practice

Three decisions follow from all of the above:

1. With a hard ceiling, set a target size rather than a quality. The quality number has no reliable relationship to the result, so let the tool measure its way there.
2. Prefer WebP for screenshots. Coloured text and sharp edges land exactly on chroma subsampling's weak spot, and WebP's block prediction has the largest advantage on that kind of content.
3. Leave already-small files alone. Every re-encode is an irreversible loss, and saving a few dozen kilobytes rarely justifies it.

Frequently asked questions

What does compression actually do?

Lossy compression does not squeeze a file smaller. It selectively discards information, choosing the parts human eyes are least sensitive to. That is why a compressed image can never be restored to the original: the discarded data is genuinely gone, unlike lossless formats such as ZIP.

What does "quality 80" mean?

It does not mean "80% of the quality is preserved", and it is not a percentage of anything. It is a scaling factor applied to a quantisation table, and every encoder ships a different table. That is why the same image at quality 80 comes out at different sizes in different tools, the number simply is not comparable across encoders.

Why can nobody calculate which quality setting produces a 4 MB file?

Because the relationship between quality and file size depends entirely on image content, with no general formula. At quality 70, a photo of open sky might land at 200 KB while a close-up of foliage lands at 2 MB, because the latter is packed with high-frequency detail. Encoding, measuring and adjusting is the only reliable approach.

Why do some images refuse to get smaller?

Because they contain no redundancy to discard. Film grain, sensor noise, dense foliage, crowds, every pixel differs from its neighbours, so nothing can be predicted or generalised. Re-compressing an already-compressed JPEG has the same problem: what could be thrown away went the first time.

Why is WebP smaller than JPEG?

JPEG processes every block independently. WebP borrows block prediction from video coding: it guesses what a block looks like from its neighbours and stores only the error. Less information to record means a smaller file. The gap is widest on flat colour and sharp edges, narrowest on noisy photographic detail.