"Lossy" does not have to mean "looks worse". This guide explains where lossy compression hides its damage, how to choose a quality setting with your eyes instead of a superstition, and the two-pass workflow that keeps photos crisp at a fraction of their camera size.
Every JPEG, lossy WebP or AVIF file is a negotiated settlement: the encoder discards information it bets you will not miss, and mostly it bets well, because the discards are aimed at what human vision is bad at seeing — fine detail in busy areas, subtle colour differences, high-frequency noise. Compress "without visible loss" therefore does not mean without loss. It means keeping the loss below the threshold of perception at the size, distance and screen the image will actually be viewed at.
The practical craft is in three decisions: getting the dimensions right before you compress, choosing a quality setting by looking rather than by folklore, and never compressing an already-compressed file. Here is each one in turn.
Key takeaways
- Resize first, compress second — quality settings only mean something at final display size.
- For WebP and AVIF, quality 75–85 is the usual sweet spot for photos; judge on your own images, at 100%.
- A compressed file that comes out bigger than the original is telling you the original was already compressed — believe it.
- Always keep the untouched master. Lossy compression is a one-way door.
Where encoders hide the damage
Lossy codecs exploit perceptual slack. In a photograph of foliage, gravel or a crowd, neighbouring pixels vary so chaotically that small changes vanish into the noise; in a clear sky or a smooth cheek, the same changes stand out as banding or blotches. This is why a single quality number produces wildly different results across images: quality 80 can be invisible on a busy street scene and unacceptable on a minimalist product photo with a graduated background.
Chroma subsampling is the other big hide. Most JPEGs store colour at half or quarter resolution while keeping brightness detail full — written as 4:2:0 in encoder settings — because eyes resolve colour poorly. It is nearly free quality on photos and painfully visible on saturated red text or sharp coloured edges, which is one more reason graphics and photos want different treatment.
The two-pass workflow that professionals use
- Start from the master. The camera original, the design export, the uncompressed file — never a file that has already been through a lossy save. Each re-encode spends quality describing the previous encode's artefacts.
- Resize to final dimensions first (the next article in this series covers sizing in depth). A 4000-pixel photo compressed hard and then displayed at 800 pixels wastes bytes describing detail the browser will throw away.
- Encode at a candidate quality — start at 80 for WebP, 82-ish for JPEG — and view the result at exactly 100%, beside the master, in the layout it will ship in.
- Step down in small increments (5 points at a time) until you can just spot a difference, then step back up one notch. That setting, for that image, is your invisible-loss point.
- Record what you used. Images from the same shoot or design system usually share a sweet spot, so one careful test sets the batch.
Reading the danger zones in a photo
Some regions complain first, so check them first. Smooth gradients — skies, studio backdrops, fog — show banding before anything else. Fine repetitive detail — hair, fabric weave, distant foliage — turns to mush or develops a watercolour smear. Hard edges against flat colour — a roofline against sky, text burned into an image — grow halos and mosquito noise. Faces deserve a dedicated look: skin tones sit in the range encoders treat most aggressively, and viewers notice face artefacts they would forgive anywhere else.
If the danger zones survive at your chosen setting, the rest of the image almost certainly has too. And judge on a representative screen: a compression setting that looks perfect on a dim laptop may show its seams on a bright, high-density phone display — and the reverse is also true, which can save you real bytes if your audience is mostly mobile.
Compression that is actually lossless
Some size wins discard nothing. Choosing the right format is one (a screenshot saved as JPEG, then re-saved as PNG, is neither small nor lossless — start again from the source). Stripping metadata is another: camera EXIF blocks, GPS coordinates, thumbnails and editing histories can add tens of kilobytes to a file that displays identically without them — and removing GPS data is a privacy improvement as well as a size one. Finally, lossless WebP and optimised PNG genuinely shrink files with bit-identical pixels, typically modestly. These wins are smaller than lossy compression's, but they are free, and they stack with it.
Mistakes and pitfalls
Compressing the same file repeatedly for different uses
Generating the web version from the original, then the thumbnail from the web version, compounds artefacts generation by generation. Every output size should be made from the master, in parallel, never in a chain.
Using one global quality setting for every image
A setting tuned on a landscape will vandalise a gradient-heavy product shot and waste bytes on a noisy crowd scene. Per-image judgement sounds slow; in practice a two-minute test per image type covers a whole library.
Comparing file sizes without comparing pixels
The smaller file is not the winner if it moved the artefacts into the subject's face. Always compare quality at display size first, then size among the versions that pass.
Common questions
Why did my compressed image come out larger than the original?
Because the source was already efficiently compressed, and re-encoding at a high quality setting spends bits faithfully describing the original's compression artefacts. A PNG of a photograph does the same thing losslessly. The fix is to go back to the master and choose a lower quality or a better format — or accept the original.
What quality number should I just use for everything?
If you must pick one blind: WebP 80 for photographs is a defensible default in most testing. But it is a default, not an answer — graphics with text want lossless treatment, and gradient-heavy images want individual attention at any number.
Does compression strip the colour profile and shift my colours?
It can: many encoders drop embedded ICC profiles, and a wide-gamut image (Display P3, Adobe RGB) displayed as if it were sRGB looks duller or shifted. Convert to sRGB explicitly for web use and keep or embed the profile, then check the result against the master.
To wrap up
Invisible compression is a viewing decision, not a setting. Work from the master, size before you squeeze, step the quality down while looking at the parts of the image that complain first, and stop one notch before they do. Do that and your readers get the photo you saw — at a tenth of the bytes.
Try it yourself
The image compressor lets you set format and quality, shows the resulting size immediately, and works entirely in your browser — ideal for the step-down test described above, with your original never leaving your device.