How to compress images without losing quality: a practical guide

"Compress without losing quality" sounds like a contradiction, and in the strictest sense it is. Lossy compression discards information by definition. But the phrase describes something real and achievable: reducing a file by 60–80% with no difference a person can see at normal viewing size.

That gap — between what a codec discards and what your eyes can detect — is large, and most images never get near it. Here is how to close it reliably.

Why your images are bigger than they need to be

Before touching a quality slider, it is worth knowing where the weight actually comes from. In practice it is almost always one of four things.

The image is far larger than it is displayed. A phone photo is around 4000 pixels wide. A blog post displays it at 800. You are storing twenty-five times the pixels that will ever reach a screen, and no amount of clever encoding fixes that.

It is in the wrong format. A screenshot saved as JPEG is both larger and worse-looking than the same screenshot as PNG or lossless WebP. A photograph saved as PNG can easily be ten times the size of the equivalent JPEG.

It carries metadata nobody wants. Camera EXIF, GPS coordinates, colour profiles, editing history, embedded thumbnails. Usually a few tens of kilobytes; occasionally, with an embedded preview, several hundred.

It was saved at quality 100. Which, as we will get to, does not mean what people assume.

Fix those four and most images are already 80% smaller before you make a single deliberate quality trade.

What the quality slider actually does

The slider is not a dial marked "how good is this picture". In a JPEG or WebP encoder it scales a quantization table — how coarsely the encoder rounds off the high-frequency detail in each block of pixels.

High frequency means fine texture and sharp transitions: the grain of fabric, individual leaves, the edge between a letter and its background. Low frequency means the broad shapes and colours. Human vision is far more sensitive to low-frequency structure than to fine texture, and lossy codecs exploit exactly that asymmetry. As you lower quality, the encoder rounds fine detail more aggressively while leaving the overall structure nearly untouched.

That is why the size-versus-quality curve has a distinct knee:

The numbers move with the image, but the shape does not. The steep part of the curve is between 100 and 85, and it costs you nothing visible. Below about 70 you start paying in ways people notice.

Quality 75–85 is the answer for almost every photograph. If you take one thing away, take that.

Why quality 100 is a trap

Quality 100 in a lossy codec is not lossless. It is the most expensive lossy setting available. The encoder still transforms and quantizes, it just rounds very finely — and what it is faithfully preserving at that setting is largely sensor noise and JPEG artefacts from a previous save.

You pay two to three times the file size to store detail nobody can see, in a format that is still throwing information away. If you genuinely need pixel-exact output, ask for lossless explicitly: PNG, or WebP in lossless mode. That is a different request, and it produces a different, honest result.

Resize first. It is not optional

This is the highest-leverage step, and it is the one most often skipped.

Take a 4000 × 3000 photo at 3.2 MB, displayed in an article at 800 pixels wide:

• Compress to quality 80 without resizing: about 900 KB.
• Resize to 1600 pixels wide (2× for high-density screens), then compress at 80: about 110 KB.

Same visible result on the page. An eight-fold difference in what the browser downloads. The reason is simple: compression reduces the cost per pixel, while resizing reduces the number of pixels, and there are a lot more pixels than there is per-pixel overhead.

Pick your target width from where the image is actually used:

Doubling for high-density displays is worth it for anything prominent, and unnecessary for thumbnails. If you are batching, resizing to a single target width across a folder is usually the single change that produces the largest saving.

Then choose the format for what the image is

Format choice is not a preference, it is a match between the encoder's assumptions and the content.

• Photographs — continuous tone, gradual variation, noise: JPEG or lossy WebP. AVIF if the image is large and prominent.
• Screenshots, charts, diagrams, line art — flat areas of colour, hard edges, text: PNG or lossless WebP. A JPEG of a screenshot is bigger and uglier, because the encoder is optimised for exactly the kind of content a screenshot is not.
• Anything needing transparency: PNG or WebP with alpha. Not JPEG, which has no alpha channel and will flatten it onto white without warning.
• Logos and icons: SVG if you have a vector source. Nothing raster competes with a few hundred bytes of path data that stays sharp at every size.

The deeper trade-offs between the raster formats are worth understanding once — we go through them in WebP vs AVIF vs JPEG, including where each one falls apart.

The mixed case, an interface screenshot with a photograph inside it, is genuinely ambiguous. Try both and compare; it takes seconds with a converter that runs locally, and the answer depends on how much of the frame is which.

Strip the metadata

Most compressors do this by default, and it is worth knowing what disappears.

A camera JPEG carries EXIF: model, lens, exposure, orientation, often GPS coordinates, sometimes an embedded preview thumbnail at several hundred kilobytes. For a web image, essentially none of it is useful and some of it is a genuine privacy problem — a holiday photo posted publicly can carry the exact coordinates of your home.

Two exceptions worth keeping:

• Orientation, if your pipeline has not already applied it. Strip it carelessly and portrait photos come out sideways.
• Colour profile, if the image is not sRGB. Strip a Display P3 profile and the colours shift, usually towards flat and desaturated.

A good compressor bakes orientation into the pixels before dropping the tag, which is why photos come out the right way up with the metadata gone.

The order of operations

Every step in the wrong order costs you quality, size, or both.

1. Start from the best original you have. Editing a file that has already been through a lossy save inherits its artefacts permanently.
2. Do all edits first — crop, rotate, colour, retouching. Every intermediate lossy save is another generation of loss.
3. Resize to the target dimensions.
4. Choose the format for the content type.
5. Compress at 80, look at it at 100% zoom, adjust once if needed.
6. Strip metadata, keeping orientation and any non-sRGB colour profile.

Steps 2 and 3 in the wrong order is the classic mistake: compress hard, then resize, and you scale up the compression artefacts along with everything else.

What to look at when you check the result

Do not check at the size it will be displayed. Check at 100% zoom, and look at the four places artefacts appear first:

• Flat gradients — skies, studio backdrops, soft shadows. Banding shows here before anywhere else.
• High-contrast edges — text over an image, a dark logo on light background. Look for the faint halo of mosquito noise.
• Fine repeated texture — hair, fabric weave, foliage, gravel. This is where a codec smears detail into mush.
• Deep shadows — blocking is most visible in dark, near-uniform areas.

If those four are clean at quality 80, the image is clean.

Batch work: pick a policy, not a per-image setting

For a folder of images, tuning each one individually is not a good use of an afternoon and it produces inconsistent results. A policy works better:

• One target width for the whole set, chosen from the largest place any of them appear.
• One format per content type — photos WebP lossy, screenshots WebP lossless.
• Quality 80 for photographs, lossless for anything with text.
• Metadata stripped, orientation applied.

Then spot-check the three most demanding images in the set: the one with the most sky, the one with the most text, and the darkest one. If those pass, the rest will.

Where this leaves you

The reason "compress without losing quality" works in practice is that most of a typical image file is not carrying visible information. It is excess pixels, the wrong encoder, metadata, and the cost of a quality setting nobody chose deliberately.

Fix those and you get most of the way to an 80% reduction before making any trade at all. The actual lossy step — quality 80 instead of 100 — is the smallest part of the saving and the only part that involves a compromise.

OpusImg's compressor runs on your own device: the codecs are WebAssembly, the file is decoded in a worker on your machine, and nothing is uploaded. That is not only a privacy property. It also means you can iterate — try 80, look, try 75, compare — without a round trip for each attempt, which is what makes checking your work practical rather than theoretical.