Lossy vs lossless compression, and when each one is wrong

Every image file is a compromise between fidelity and size. The two families of compression make that compromise in fundamentally different ways, and choosing badly is the most common reason images look wrong on the web.

Lossless keeps every pixel

Lossless compression stores the image exactly, using clever encoding to describe repetition more compactly. A row of two hundred identical white pixels can be recorded as "white, two hundred times" instead of listing each one. Decompress the file and you get back precisely what went in, bit for bit.

PNG works this way, which is why it excels at flat colour, hard edges and text. A screenshot of an interface compresses beautifully: large areas of identical colour, sharp boundaries, few gradients.

Give PNG a photograph and the same mechanism works against you. Photographs have almost no exact repetition — every patch of sky is subtly different — so there is little for the encoder to collapse. A 12-megapixel photo saved as PNG can easily be twenty times larger than the same image as a good JPEG, with no visible benefit.

Lossy discards what you are unlikely to notice

Lossy compression throws information away permanently, guided by models of human vision. We are more sensitive to brightness than colour, and to large shapes than fine texture, so encoders spend their budget accordingly: colour detail is reduced, subtle high-frequency variation is simplified.

Done well, the result is visually indistinguishable at a fraction of the size. Done aggressively, you see the machinery: blocky squares in skies, halos around text, smeared detail in shadows.

JPEG, and the lossy modes of WebP and AVIF, all work this way.

Generation loss is real

Because lossy encoding discards data, each round trip compounds the damage. Open a JPEG, make a small edit, save it again, and you have re-encoded an already-degraded image. Do that a dozen times and the artefacts become unmistakable.

The practical rule is to keep originals and always export from them, rather than editing exports. If you are running a batch through a processing tool, run it once from the masters with your final settings, not repeatedly from previous outputs.

Choosing in practice

Photographs: lossy, at quality 80 to 90. The size difference against lossless is enormous and the visual difference is not.

Screenshots, logos, diagrams, anything with text: lossless, or lossy at very high quality. Text is exactly the kind of high-contrast, high-frequency content that lossy encoders handle worst.

Anything with transparency: PNG, WebP or AVIF. JPEG has no alpha channel at all, so transparent areas must be flattened onto a colour.

The bigger lever

Before agonising over quality settings, check your dimensions. A photograph displayed at 800 pixels wide but saved at 4000 is carrying twenty-five times the pixel data it needs, and no compression setting will fix that as effectively as resizing will. Compression is the second decision; resolution is the first.

Reading the artefacts

Once you know what each failure looks like, you can diagnose a bad image in a glance rather than guessing at settings.

Blocking — visible 8×8 squares, most obvious in skies and other smooth areas — is JPEG running out of budget. The encoder divides the image into blocks and, at low quality, no longer has enough bits to describe the transitions between them.

Ringing — faint halos following a high-contrast edge — appears around text and hard graphic boundaries. It is the mathematical consequence of describing a sharp step with a limited number of frequency components, and it is why lossy formats and typography are a poor match.

Colour bleeding — a red caption whose colour smears past its letterforms — is chroma subsampling, not the quality setting. Raising quality reduces blocking but leaves this untouched, which is why a "maximum quality" JPEG screenshot still looks wrong.

Banding — visible steps across what should be a smooth gradient — comes from a combination of 8-bit precision and aggressive quantisation. AVIF handles this noticeably better than JPEG, which is its clearest practical advantage.

Quality numbers are not a scale

A quality value of 80 does not mean "80% of the original". It is an index into an encoder-specific quantisation table, and the tables differ between formats and between implementations of the same format.

This has two practical consequences. First, JPEG at 80 and WebP at 80 are making different trade-offs, and the WebP file will typically be considerably smaller at similar perceived quality. Second, quality settings are not portable between tools: one library's 85 can look like another's 75.

The only reliable method is to judge by eye on your own content, at the size it will be displayed, and then reuse the setting that worked. A number that produced a good result on studio product shots may be too aggressive for landscape photographs full of fine foliage.

Where the choice is made for you

Some contexts remove the decision. Print labs generally want maximum-quality JPEG or TIFF, because paper reveals gradient artefacts that screens forgive. Marketplaces specify JPEG and re-encode anyway. Email clients cannot be relied upon to render WebP at all.

In each of those cases the right move is to give the downstream system the best input you can and let it make its own compromises, rather than pre-compressing and having the damage compounded by a second lossy pass you do not control.