compression · formats · fundamentals
Lossy vs lossless compression, explained with real examples
What each type of compression actually throws away, why generation loss compounds, and a decision rule for choosing between them every time.
Lossless compression makes a file smaller and gives you back exactly what you put in. Lossy compression makes it much smaller and gives you back something similar.
That is the whole distinction, and everything interesting follows from what "similar" means, how the similarity degrades when you repeat the process, and which kinds of image each approach was designed for.
Lossless: finding the redundancy
Lossless compression exploits the fact that real data repeats itself. Decompression reverses the process perfectly — the output is bit-for-bit identical to the input.
The simplest illustration is run-length encoding. A row of forty identical white pixels can be stored as "white × 40" instead of forty separate values. Real formats are more sophisticated, but the principle holds: find structure, describe it more briefly.
PNG does two things in sequence. First it filters each row, storing the difference from the pixel to the left or above rather than the absolute value — in a smooth gradient those differences are nearly all the same small number, which is highly compressible. Then it runs DEFLATE over the result, which finds repeated byte sequences and replaces them with references.
That is why PNG is spectacular on screenshots and useless on photographs. A screenshot is full of exact repetition: identical background pixels by the thousand, the same anti-aliased letterform recurring, flat panels of interface colour. A photograph has almost none — sensor noise alone means no two "identical-looking" pixels are actually identical, so there is nothing to reference.
Real numbers on a 1920 × 1080 image:
| Content | PNG size | Why |
|---|---|---|
| Application screenshot | ~180 KB | Huge flat areas, repeated glyphs |
| Line drawing, few colours | ~40 KB | Almost entirely repetition |
| Photograph of foliage | ~4.2 MB | Every pixel differs from its neighbours |
| Photograph as JPEG q80 | ~290 KB | Fourteen times smaller than the PNG |
The photograph as PNG is not just large, it is larger than the raw uncompressed data would be in some cases, once you account for how little redundancy there is to find.
Lossy: discarding what you will not miss
Lossy compression starts from a different question: not "what repeats?" but "what can I throw away without you noticing?"
JPEG, WebP and AVIF all work roughly the same way:
- Convert to a colour space that separates brightness from colour. Human vision is far more sensitive to brightness detail than to colour detail.
- Subsample the colour channels. Store colour at half resolution. This alone removes half the data and is essentially invisible on photographs.
- Transform blocks of pixels into frequency components — how much fine detail, how much coarse structure.
- Quantize. Round the fine-detail components coarsely and the coarse-structure ones finely. This is the lossy step, and the quality slider scales how coarse the rounding is.
- Losslessly compress the result, because after quantization there is a lot of redundancy to find.
Step 4 is where the information goes, and it is directed by a model of human vision. That is why a lossy image at quality 80 can be a fifth of the size with no visible difference: the discarded data was disproportionately the data you were least able to see.
The corollary is that lossy compression assumes the image is a photograph. Applied to a screenshot, the assumptions are wrong in every particular — the "fine detail" it discards is the crisp edge of your text, and the block boundaries it introduces sit right where flat colour makes them most visible.
Generation loss: the thing that actually bites people
Lossless compression can be repeated forever with no effect. Decompress a PNG, re-save it as PNG, a hundred times: the hundredth is identical to the first.
Lossy compression degrades every time. Each save quantizes what the previous save already quantized, and the artefacts of round one become "detail" that round two must encode and then damage further.
An illustrative sequence on a photograph saved at quality 80 each time:
| Generation | Visible state |
|---|---|
| 1 | Indistinguishable from the original |
| 2 | Still indistinguishable in practice |
| 5 | Slight softening in fine texture |
| 10 | Visible blocking in sky and shadow; edge halos |
| 20 | Obviously degraded |
The insidious part is how easily generations accumulate without anyone deciding to accumulate them. Photograph taken as JPEG (generation 1). Cropped and re-saved (2). Sent via a messaging app that re-encodes it (3). Downloaded and colour-corrected (4). Uploaded to a platform that re-encodes (5). Someone screenshots it and shares it (6). Nobody made a bad decision at any step.
Three rules follow, and they are the practical payload of this article:
- Keep a lossless master. Do your editing on a PNG, TIFF or raw file and export lossy versions from it. Never edit the exported JPEG.
- Do all edits before the lossy save. Crop, rotate, colour, retouch, then encode once. Two edits with a save in between is two generations.
- Never re-save a lossy file at higher quality "to preserve it". The damage is already in the pixels. You are storing artefacts precisely, at greater expense.
Where the decision actually gets made
The choice is dictated by content, not preference.
Use lossless when the image contains hard edges, flat colour, or text.
- Screenshots and screen recordings, including the frames you use for documentation.
- Diagrams, charts, and line art.
- Logos, icons, and UI assets.
- Anything with transparency that must stay crisp.
- Masters and archives.
- Medical, scientific and forensic images, where a fabricated detail is a serious problem rather than a cosmetic one.
Use lossy when the image is a photograph.
- Photographs on the web, in email, on social platforms.
- Product images, gallery images, hero images.
- Anything where the file is a final delivery rather than a source.
The mixed case — a screenshot containing a photograph, a document scan with a picture in it — is genuinely ambiguous. Try both and compare; it takes seconds with a converter that runs locally, and the answer depends on what fraction of the frame is which. If a screenshot is going to be dressed up with a background and shadow before publishing, do that first and encode the composite once.
The four things people get wrong
"Lossless means better quality." It means identical to the input. A lossless conversion of a quality-60 JPEG faithfully preserves quality-60 artefacts in a much larger file. If the input was already damaged, lossless preserves the damage perfectly. It is a fidelity guarantee, not a quality upgrade.
"Quality 100 is lossless." It is not. It is the most expensive lossy setting, still transforming and quantizing, just very finely. It typically produces a file two to three times larger than quality 90 for no perceptible gain. If you want lossless, ask for lossless — the formats support it explicitly.
"PNG is higher quality than JPEG." PNG is lossless, which is different. For a photograph, a quality-90 JPEG is visually indistinguishable from the PNG at a tenth the size. For a screenshot, the PNG is both smaller and genuinely better looking. The formats are matched to content, not ranked.
"WebP is the lossy one and PNG is the lossless one." WebP is both, and so is AVIF. The format name does not tell you which mode a given file used, which is exactly why "save it as WebP" is not a complete instruction. Whether the encoder is in lossy or lossless mode is a separate choice from the container.
A decision rule you can apply without thinking
Ask: is this image a photograph, and is this the final delivery?
- Yes to both: lossy, quality 80. Encode once, from the master.
- Photograph, but it is a master or will be edited again: lossless.
- Not a photograph — text, flat colour, hard edges, transparency: lossless, always.
- Uncertain: try both, compare at 100% zoom, take the smaller one that looks right.
That last option is not a cop-out. It is a two-second experiment that answers the question definitively for your specific image, and it is more reliable than any rule of thumb applied to content you have not looked at. OpusImg's compressor runs the codecs in your browser via WebAssembly, so trying three settings costs three seconds and no upload — which is what makes "just compare them" a practical instruction rather than a theoretical one.
Why the distinction is not going away
Every few years a new format arrives with better compression at both ends of the spectrum. What does not change is the underlying trade: information you discard cannot be recovered, and information you keep costs bytes.
Better codecs move the curve — they discard more intelligently, so a modern format at a given visual quality is smaller than an old one. They do not remove the choice. AVIF still has a lossy mode and a lossless mode, and you still have to know which one your image needs, for exactly the same reasons as thirty years ago.
Learn the rule once and it will keep working through however many format generations follow.
We build the browser-based image tools this guide refers to, which is also how we know where they stop being the right answer.
Tools covered in this article
Keep reading
- WebP vs AVIF vs JPEG: which format should you actually use in 2026A practical comparison of JPEG, WebP and AVIF — how much each really saves, where each one breaks down, and how to choose without guessing.6 September 2026 · 8 min read
- How to compress images without losing quality: a practical guideWhy images are usually far bigger than they need to be, what the quality slider really controls, and a repeatable order of operations that works.6 September 2026 · 8 min read
- Why browser-based image processing is more private than any upload toolWhat actually happens when you upload an image to a free online tool, why in-browser processing is a different guarantee, and where the line honestly sits.6 September 2026 · 8 min read