How to Reduce Image File Size Without Losing Quality

There are two honest answers to this, and they are very different in scale. Truly lossless compression — every pixel identical afterwards — typically saves somewhere between 5 and 25% on an already-encoded file. Visually lossless compression, where detail is discarded but no viewer could tell, routinely saves 60 to 80%. Almost everyone asking the question wants the second, and the first is what the phrasing describes.

The distinction matters because the two use different techniques. Lossless work is stripping metadata, re-encoding with a better compressor, and removing redundancy the original encoder missed. Visually lossless work is choosing a modern format, matching dimensions to actual use, and setting quality at the threshold where artefacts stop being perceptible. The second set is where the bytes are.

The framing that makes this tractable is that most images carry data nothing is using. A 4000-pixel photograph displayed 800 pixels wide, saved at quality 95 as a JPEG, with a full embedded colour profile and camera metadata, is perhaps four times larger than the visually identical file. Nothing is lost by fixing that, in any sense a viewer would recognise.

Lossless compression stores the same pixels in fewer bytes by finding redundancy — repeated patterns, predictable gradients, runs of identical colour. Decompress it and you get the original back exactly. PNG works this way, as do the optional lossless modes of WebP and AVIF.

Its limitation is that photographic content has very little exploitable redundancy. Real-world detail is noisy, and noise is incompressible almost by definition. That is why a photograph saved as PNG is often several times larger than the same photograph as a good JPEG, and why lossless re-encoding of an existing JPEG saves a modest amount rather than a transformative one.

Where lossless genuinely shines is flat colour and hard edges — screenshots, logos, diagrams, line art. For those, lossless is both smaller and better, because lossy compression produces visible haloes around exactly the sharp transitions those images are made of.

Before touching pixels, there are bytes to remove that carry no image information at all. A photograph off a phone or camera arrives with EXIF data, a colour profile, sometimes an embedded thumbnail, and occasionally editing history from whatever software touched it last. On a large file that is a small percentage; on a small one it can be a third of the total.

Keep the colour profile if colour accuracy matters — stripping it can shift colours visibly on wide-gamut images — and strip the rest. Location metadata in particular is worth removing before publishing anything, for reasons unrelated to file size.

The other free win is the encoder. Not all encoders for the same format are equally good, and a modern one produces a smaller file at identical quality than the one that originally wrote the image. This is why re-encoding a JPEG at high quality can produce a smaller file that looks the same — you are not removing more detail, you are storing it more efficiently. It is also the one place "compress without losing quality" is close to literally true for a lossy format.

This is where most of the waste lives, and it is not a compression question at all. File size scales roughly with pixel count, so an image at twice the width and height it is displayed at carries about four times the necessary data. Phone cameras produce images 3000 to 4500 pixels wide; a typical web page displays them at 800 to 1200.

Reducing dimensions to match actual use is lossless in every sense a viewer experiences, because the discarded pixels were never being shown. The rule of thumb worth keeping is to size the source at about twice the largest displayed width, which covers high-density screens without paying for resolution beyond what they can resolve.

The exception is an image people will zoom into — a product detail, a map, artwork. There the extra pixels are being used, and the saving has to come from format and quality instead.

Quality settings are not linear in perceptual cost, which is what makes a threshold approach work. Between 100 and about 85 you are removing detail almost nobody can see under any conditions. Between 85 and 75 the loss is visible only under close comparison of the two files side by side. Between 75 and 60 it becomes apparent on skin tones, smooth gradients and text. Below 60 it is obvious: blocking around hard edges, banding in skies, a general mushiness.

So 80 is the number worth remembering — comfortably inside the invisible range for photographs, and a very large saving over the 95 that most software defaults to.

Content shifts the threshold. Photographs with fine texture tolerate lower quality than smooth studio images, because texture masks artefacts while flat gradients expose them. Anything with text in it needs 90 or above, since lossy compression attacks sharp edges specifically. And an image that will be re-edited later should stay high or lossless, because each lossy save compounds the damage from the last.

JPEG and WebP normally store colour at half the resolution of brightness, on the sound basis that human vision resolves brightness detail far better than colour detail. That is chroma subsampling, usually written 4:2:0, and it saves a useful amount of data with no visible effect on photographs.

It has one specific failure mode: saturated, hard-edged colour boundaries. Red text on a white background, a thin coloured line, a sharp logo edge — these develop visible colour bleeding, because the colour information genuinely is being stored at half resolution and the edge falls between samples.

The fix is to switch to full colour resolution, 4:4:4, for those images. It costs perhaps 15 to 20% more bytes and removes the bleeding entirely. For photographs, leave subsampling on; for anything with coloured text or graphics in it, turn it off.

Lossy compression is not idempotent. Each save discards detail based on what is present, so compressing an already-compressed file removes a second layer of detail from an image that has already lost some — and the artefacts of the first pass become content the second pass tries to preserve. Do it a few times and the image visibly falls apart.

In practice this happens through workflow rather than intent. An image is exported from a design tool, run through a compressor, uploaded to a platform that re-encodes it, then downloaded and re-used somewhere else. Nobody chose to compress it four times.

The defence is to keep an original and always work from it. Archive the highest-quality version you have — the camera file, the lossless export — and generate every derivative from that, rather than from the last derivative you happened to make. Where a platform is going to re-encode on upload, hand it a good-quality file rather than a pre-squeezed one, so its single pass is the only lossy step.