How to Compress an Image Without Making It Worse
Two dials decide almost everything about an image's file size, and most people only touch one of them. This guide is about using both, and about knowing when compression has nothing left to give.
The two levers, in order of impact
Image Compressor exposes them directly:
- Max width in pixels — default 1920. Height scales proportionally, and if you clear the field there is no width limit.
- Quality — a slider from 1 to 100, default 80, which is passed to the encoder as 0.01 to 1.00.
Downsampling wins on cost-per-unit-of-visible-quality. A photograph straight from a phone is often 3000–4000 pixels wide. If it will be displayed 800 pixels wide on a page, everything beyond that is pure weight. Dropping 4032 → 1920 pixels removes roughly four-fifths of the pixels before the quality slider is even consulted. Set the width first, then tune quality.
The width control only ever shrinks. An image narrower than your max width is left at its own size — the tool never enlarges, so a "max width 2000" pass over a 1200-pixel photo changes nothing dimensionally.
Typed values are used as entered. The input box carries a 50–10000 range, but that is the browser's widget hint rather than a hard check in the code, so if you type something extreme you will get exactly what you typed.
What quality actually does
Quality controls the lossy encoder for JPEG and WebP. Roughly:
- 90–100 — near-source fidelity, large files, almost never worth it on the web.
- 75–85 — the normal publishing range. Artefacts are hidden by viewing size.
- 60–70 — visible softening in gradients and fine texture; acceptable for thumbnails and previews.
- Below 50 — blockiness and colour smearing appear around edges and in skin tones.
Two things follow. First, quality has no effect on PNG output. PNG is lossless, so the encoder ignores the number entirely; the "quality" slider going from 80 to 10 on a PNG pass changes nothing except your expectations. To shrink a PNG you must reduce its dimensions or convert it to a lossy format — see image format conversion.
Second, every pass is a fresh re-encode. The original bytes are never reused, and metadata is dropped: EXIF capture data, GPS coordinates, colour profile and thumbnails do not survive. That is usually a privacy plus, but it means the tool is not a way to "lightly touch" a file while keeping its record.
When compression makes the file bigger
This is the most common surprise, and it is not a malfunction:
- A well-optimised JPEG re-encoded at quality 80–90 can easily grow. The encoder spends bytes differently than the original one did.
- A PNG that is mostly flat colour is already compressed extremely well. Re-encoding it as PNG changes almost nothing.
- A tiny image has fixed overhead that dominates its payload, so any percentage change looks dramatic.
The interface reports Before, After, and a percentage with a minus sign in front of it. When the file has grown, that sign and the negative number combine into something like --20.0%. Read the magnitude, not the decoration: the output is 20% larger, and you should pick a lower quality, a smaller width, or a different format.
If the after size is not smaller, do not download it. Keep the original.
Reasonable targets
Approximate, for a typical 16:9 photograph or 1920-wide screenshot:
| Use | Width | Quality | Realistic size |
|---|---|---|---|
| Full-width web hero | 1600–1920 | 70–78 | 150–350 KB |
| In-article photo | 800–1200 | 72–80 | 60–150 KB |
| Thumbnail / card | 300–500 | 65–75 | 15–40 KB |
| Email attachment | 1280–1600 | 75–80 | 150–300 KB |
| Screenshot with text | 1200–1920 | 85–95, or PNG/WebP lossless | legibility first |
The last row matters more than the numbers suggest: text on a coloured background is exactly what lossy compression damages first. Compress aggressively, then zoom to 100% and read the smallest label in the image. If it is fuzzy, that region of the file is the constraint, not the byte target.
A workflow that does not waste time
- Decide the display width the image will ever be shown at. Set max width once.
- Compress at quality 80. Look at the percentage saved.
- If the file is still too big, step quality down by 10 and re-run — do not jump to 30.
- Judge the result at 100% zoom on the areas that carry information: text, faces, edges, thin lines.
- If you have hit a wall, change format rather than lowering quality further. A PNG screenshot often becomes half the size as WebP with no visible loss.
Compression is a loop, and it is short. Two or three passes should land it.
Not for batches, and not for documents
One file per run. If you have a folder of images, Image Batch Processing resizes and re-encodes many files in one pass — PNG, JPEG and WebP only — and returns a ZIP. Note that it re-encodes everything it processes, so a batch run with untouched settings will still rewrite every file.
For making a PDF smaller, use PDF Compression instead; that is a document pipeline with different trade-offs, covered in how to reduce PDF file size.
Privacy
Compression runs entirely in the browser tab. The file is read locally, resized on a local canvas, and encoded locally — no upload, no queue, no account, and it works offline once the page is loaded. The only outbound requests are the page's analytics and advertising scripts.
Related guides
- How to convert an image to PNG, JPEG, or WebP — what changes in a re-encode, and the transparency rules
- Batch resize and convert images: what to know first — the same trade-offs across many files
- How to stitch screenshots into one long image — and why the result then needs compressing