How to Compress Images Without Losing Quality

Being precise here is what makes the rest of the advice usable.

Mathematically lossless. Every pixel comes back identical. Available from PNG, WebP's lossless mode, and AVIF's lossless mode. The saving is limited to whatever redundancy exists in the image, so a screenshot compresses well and a photograph barely does.

Visually lossless. Data is genuinely discarded, but the difference is imperceptible in normal viewing. This is what a high-quality JPEG or WebP gives you, and it is the right target for almost all photographic work — the savings are enormous compared with lossless, and nobody can tell.

Smaller with no downside at all. Also real, and usually ignored: fewer pixels than you were displaying, metadata you did not need, and a more efficient encoder for the same picture. None of these costs visible quality because none of them changes what the viewer sees.

The trap is asking for the first when you want the second. Insisting on mathematical losslessness for a photograph on a web page means a file several times larger than necessary, for a difference no visitor could detect on any screen they own.

If you need every pixel intact — a master copy, a medical or legal image, artwork mid-project, anything to be edited again — you have three real options.

WebP lossless. The most useful of the three, and underused. Google's published figures put WebP lossless at 26% smaller than PNG, with transparency costing "just 22% additional bytes". Converting a PNG to WebP lossless is a free 26% with no pixel changed at all. Every current browser reads it, and the format comparison covers where each of the three still wins.

PNG, optimised. Already lossless. What remains is reducing the colour palette where the image genuinely has few colours — an 8-bit PNG of a two-colour logo is a fraction of the 24-bit version, and identical to look at. Dedicated PNG optimisers squeeze further by tuning filter strategies.

AVIF lossless. Smaller again in principle, though support for encoding it in a browser is less consistent, which is why the compressor checks at load time whether your browser can actually produce it rather than offering an option that will fail.

What lossless cannot do is make a photograph small. There is no redundancy to exploit in a picture of grass, so a lossless photograph stays several megabytes. If that is your situation, you want the next section.

These are perceptual guidelines from practical use rather than figures from a specification — your own eyes on your own images are the real test, which is what the before/after slider is for. But they are a reliable starting point.

The curve is the important part: between 100% and 85% the file shrinks a great deal and the picture does not change much, and below about 70% the file barely shrinks further while the picture degrades quickly. That is why 80% is the default in so many tools, and why the compressor's Web preset sits there.

Test where it hurts, not where it does not. Drag the comparison slider over hair, foliage, fabric texture, or text — the high-frequency detail lossy compression attacks first. A flat wall will look perfect at 40% and tell you nothing.

A single recommendation cannot cover these, because they fail in different ways at different settings.

Photographs. The ideal case. WebP or JPEG at 80–85%, resized to the dimensions you display. Expect 60–80% smaller than the camera original with no visible change.

Screenshots and UI captures. The worst case for lossy compression: hard edges and text are exactly the high-frequency content that gets discarded, so text picks up a visible halo at settings a photograph would shrug off. Keep them lossless — WebP lossless is the best answer, and it is where PNG screenshots see their largest wins.

Logos, icons and line art. Lossless, and preferably SVG if you have the vector original, which is both smaller and infinitely scalable. A lossy logo shows coloured fringing around every edge.

Illustrations with flat colour. Lossless, or a reduced palette. Flat areas offer nothing for artifacts to hide behind, so banding appears early.

Images with transparency. WebP handles both lossy and lossless with an alpha channel — Google notes lossy WebP with transparency is typically around three times smaller than PNG. A JPEG cannot carry transparency at all and will fill it with black or white.

Anything to be edited later. Lossless, always, and keep the original. Each lossy save re-quantises an already-quantised image, and the damage accumulates in a way no later step can undo.

Before touching a quality setting, three reductions have no visual cost whatsoever.

Show fewer pixels. If an image displays at 800 pixels wide and the file is 4000 pixels wide, five sixths of the data is invisible on that page. Resizing to the display size is not a quality compromise — it is removing data that never reached the screen. This is nearly always the largest single saving available, and the sizing guide covers how to work out the number you need, including for high-density displays.

Change format. Same picture, better encoder. WebP against JPEG at equivalent quality is a 25–34% saving by Google's measurement; AVIF further again, at a median 50% against JPEG where WebP manages 30% on MDN's figures.

Remove what is not the image. EXIF blocks, embedded thumbnails and colour profiles are not pixels. On a large photograph they are noise in the numbers; on a small graphic they can be a real proportion of the file, and stripping location data is worth doing on anything public regardless.

Do these three first and many images reach their target before quality enters the conversation at all.

A note for anyone delivering images to someone else, because "compressed without losing quality" is a claim people make loosely.

If you used a lossy format at any setting, data was discarded. That is worth saying plainly rather than implying the file is untouched — particularly to a photographer, a designer or a client who may reasonably want the master. "Visually identical at normal viewing size" is both accurate and reassuring; "no quality loss" is neither, if you exported at 80%.

Two practical habits follow. Keep an untouched original of anything that matters, in the format it arrived in. And when a file has already been through compression once, resist re-compressing it — you cannot recover what the first pass removed, and re-encoding usually makes the file larger while preserving the first encoder's artifacts faithfully. The compressor spots that case, keeps your original bytes and marks the row "Already optimised", which is the correct outcome even though it looks like nothing happened.