How to Compress an Image

Everything happens on your own machine — the image is decoded, re-encoded and measured in the browser, and the worker script that does the heavy lifting is served from this site rather than a third-party CDN. Nothing is uploaded, which matters for client work, screenshots of internal systems, and photographs of people who have not agreed to be on someone else's server.

The presets exist because format, dimensions and quality interact, and choosing them one at a time leads people to strange combinations like a full-resolution PNG at 40% quality.

Two details worth noticing. The Web preset drops to JPEG automatically if the browser cannot encode WebP, rather than silently failing. And Archive is the only preset that keeps your metadata — the others strip it, which removes the camera model, the timestamp and any GPS coordinates along with a few kilobytes.

If you are picking manually, the useful defaults are 80% quality for photographs on the web and 90–95% for anything you might print or edit again. Where the quality thresholds actually sit goes into the numbers per image type.

Forms and email systems specify limits in kilobytes, not quality percentages, and guessing at a slider to satisfy one is miserable. Target-size mode does it properly: you give it a ceiling and it steps the quality down repeatedly until the output fits underneath, up to twelve attempts.

Common ceilings people are handed:

What target-size mode guarantees is a ceiling, not a precise figure — you asked for "no more than", and you get the largest file that fits, which is the right behaviour. The size actually achieved is reported for every image.

The one way to make it fail is to ask for something the dimensions cannot support. A 4000-pixel-wide photograph squeezed under 50 KB has to destroy the picture to get there, because quality is the only lever left. Give it a longest-edge limit as well and the same target becomes easy — fewer pixels means fewer bytes to spend on each of them.

Compression is the last step, not the first. Doing these in order takes the same amount of time and produces a much better result:

1. Crop to what you are actually showing. Pixels outside the crop cost bytes for nothing.
2. Resize to the dimensions the image will be displayed at. This is the quadratic one — halving the width and height quarters the pixel count.
3. Convert to an efficient format. Google puts WebP at 25–34% smaller than JPEG at equivalent visual quality, which is a saving with no visible cost at all.
4. Strip metadata if the file is small enough for tens of kilobytes of EXIF to matter, or if it contains location data you would rather not publish.
5. Then set quality, and only as far as you need.

Most people start at step 5, pull the quality down until the number looks acceptable, and end up with a visibly damaged image that is still larger than a properly resized one would have been. If you only ever do one of these five, do step 2.

Queue as many files as you like; settings apply to the whole batch, so you configure once. Each file reports its own progress and its own outcome, so one problem image does not take the rest down, and you can cancel partway through without losing what has already finished. At the end, one ZIP.

Two behaviours in a batch that are worth understanding before they surprise you.

Some files may come back marked "Already optimised". That is the safeguard working. If re-encoding would produce a larger file than the original — which happens routinely with images that have been compressed before, because the first encoder's artifacts are themselves detail the second one has to preserve — the tool keeps your original bytes rather than handing you a worse, bigger copy. It is on by default and can be turned off.

Mixed folders give mixed results. A batch of camera JPGs will typically drop 60–80% at 80% quality. A batch of PNG screenshots will barely move unless you change the output format, because quality settings do not apply to PNG at all. If your batch is mostly screenshots, set the output to WebP and the same files will often shrink by 80–90%.

Very large batches are limited by the memory your browser tab can hold rather than by the tool, so for several hundred high-resolution files work in groups of thirty or forty.

Compressing before cropping and resizing. Covered above, and the single most common waste.

Overwriting your only original. Compression is one-way. Keep the source somewhere, especially for anything you might edit or print later.

Chasing a small number with quality alone. Below about 60% the artifacts are visible to anyone, and you will get a smaller, cleaner file by removing pixels instead.

Expecting a PNG to shrink. It will not, not meaningfully, until you change the format. The tool says so when it detects the case, and offers the WebP switch in one click.

Compressing an animated GIF. Re-encoding goes through a canvas, which handles one frame, so you get a still image. The tool warns rather than silently flattening your animation — for real GIF work you need software built for it.

Assuming the upload limit means what you think. Some systems measure the encoded size of the attachment rather than the file on disk, which is around a third larger. If a file at exactly the limit is rejected, aim about 25% under it. More reasons a file is still refused are worth a look before you retry.