The rule of thumb, and where it breaks
Lossy compression throws information away, so it should always produce a smaller file than lossless. That is true for photographs and false often enough to be worth understanding.
What decides it is how predictable the image is.
Lossless encoders work by finding repetition and structure — a run of identical pixels, a row that resembles the row above it, a palette of sixteen colours used across the whole image. Give one a screenshot and it will find enormous regularity and encode it almost for free.
Lossy encoders work by discarding detail the eye is bad at noticing, mostly in colour and in high-frequency texture. Give one a photograph and there is a great deal to discard. Give it a logo on a flat background and there is almost nothing — but it still pays the full cost of its transform, and worse, it produces visible ringing around the sharp edges it was never designed for.
Before you read on
You save the same photograph twice: once lossless, once at high-quality lossy. Which file is smaller?
It depends on the image. A photograph is full of noise and gradients that lossy compression discards cheaply, so lossy wins comfortably. A flat graphic with large areas of identical colour compresses superbly losslessly, and encoding it lossily can make it both larger and visibly worse. The content decides, not the format.
What wins, and when
| Content | Usually smaller | Why |
|---|---|---|
| Photographs | Lossy, by a lot | Noisy and detailed; there is a great deal to discard |
| Screenshots, UI | Lossless | Large flat areas, repeated rows, few distinct colours |
| Logos, icons, line art | Lossless | Sharp edges are exactly what lossy handles worst |
| Charts and diagrams | Lossless | Flat fills plus text; text ringing is very visible |
| Anything with text in it | Lossless | Ringing around glyphs is the most noticeable artefact there is |
| Very small images | Either — often neither | Header overhead dominates below a few hundred bytes |
The last row is the one that surprises people. Below roughly a kilobyte, the container costs more than the content, and a conversion can genuinely make a file larger. That is not a bug in the converter.
A worked example
A 32×32 test image with a smooth gradient, a hard-edged red square and saturated primaries — deliberately awkward, and roughly what a small UI element looks like:
source PNG 1,805 bytes
lossless WebP 146 bytes pixel-for-pixel identical
lossy WebP q80 264 bytes mean error 5.5 per channel
The lossless file is 80% smaller than the lossy one, and it is also exact. Both facts come from the same cause: the image is mostly flat colour and hard edges, which is the best case for a lossless encoder and close to the worst case for a lossy one.
Those figures are from this repository’s own test suite, which encodes that image on every commit and decodes it again with a different library to check the pixels survived.
How to decide without guessing
Try both and compare. It takes a second, it costs nothing, and it is more reliable than any rule of thumb — including this page’s.
Failing that, ask one question: does this image have large areas of exactly the same colour, or sharp edges between colours? If yes, start with lossless. If it is a photograph, start with lossy at around quality 80 and only go higher if you can see a difference at full size.
What none of this changes
Compression choice does not affect the image’s dimensions, and resizing is almost always the larger saving. A 4000-pixel-wide photograph displayed in a 600-pixel column wastes far more bytes than any encoder setting will recover — scale it first, then choose a format.
Metadata is a third, separate layer. An image metadata remover can omit descriptive PNG chunks or JPEG application segments without changing either the dimensions or the encoded image payload. That is useful for privacy and provenance hygiene, but it rarely competes with resizing or photographic compression as a size reduction.
Common questions
Should I just always use lossless then?
No. For photographs lossy is dramatically smaller — often five to ten times — and the loss is genuinely hard to see at sensible quality settings. The rule is about content: photographs compress well lossily because they are noisy and detailed, and screenshots compress well losslessly because they are flat and repetitive.
Why did my tiny image get bigger when I converted it?
Because every format has a fixed header cost, and below a few hundred bytes that overhead dominates whatever the compressor saves. A single-pixel PNG converted to WebP can come out larger simply because the RIFF container costs more than the pixel data. This is normal and it is why a converter should report the direction it actually measured rather than assuming a saving.
Does lossless mean the file is identical?
It means the *pixels* are identical, not the bytes. A lossless WebP made from a PNG is a completely different file that decodes to exactly the same image — every channel of every pixel matching the original. That is a testable property, and it is the one worth testing.