Compress an Image Without Uploading It
Quality search runs in your browser, on your files. Close the tab and nothing remains anywhere.
Why every other compressor wants your file
The familiar workflow — choose a file, wait for an upload of tens of megabytes, wait again for the download — has a second cost that is rarely mentioned. The image now exists on someone else's disk, in their logs, and in whatever backup or CDN copy sits behind them. For a photo of a passport, a medical scan, a client's unreleased product, or a child, that is a real disclosure. This page decodes the image with the browser's own codecs and re-encodes it in the same tab. Nothing is transmitted, which you can confirm in the Network panel while it works.
What actually shrinks an image
| Lever | Typical effect | What it costs |
|---|---|---|
| Lowering JPEG quality | The dominant lever — quality 75 is often 4–8× smaller than 95 | Visible blocking in flat areas and around edges |
| Chroma subsampling (4:2:0) | 20–35% smaller than 4:4:4 | Colour detail at sharp edges; rarely noticed in photos |
| Switching to WebP | 25–34% smaller than JPEG at matched quality | Loss of support in very old software |
| Switching to AVIF | Often 40–50% smaller than JPEG | Slowest to encode; still patchy in older editors |
| Dropping EXIF metadata | A few KB to 100 KB+ | Losing camera settings, GPS coordinates, capture time |
| Resizing to fewer pixels | Directly proportional to pixel count | Real resolution, permanently |
Every JPEG re-encode is lossy. Open a JPEG, save it at quality 90, repeat ten times, and the image visibly degrades even though each step seemed mild. Compress from the original every time — never compress an already-compressed file as your working copy.
How the target-size mode works
When you ask for 'under 100 KB', there is no formula: the relationship between quality and file size depends entirely on the image content. A portrait against a plain wall compresses far better than a photograph of foliage. The reliable approach is a search — encode at a high quality, measure the actual byte count, step down, and stop at the highest quality that fits. That is what this tool does, using a ladder of quality steps and reporting the quality it settled on, so you know how much you spent.
Which format to pick
- JPEG — photographs, and anything you will send to a print shop or an older system. Universally readable.
- WebP — the best general default for the web today: smaller than JPEG at equal quality, supports transparency, and is understood by every current browser.
- AVIF — the smallest of the three and the best choice for a website you control, provided your encoder can afford the time.
- PNG — the wrong choice for photographs, because it is lossless and thus large. The right choice for screenshots, diagrams, text and anything needing transparency or exact pixels.
What to check after compressing
- Zoom to 100% and look at a high-contrast edge, not the whole image — that is where compression artefacts show.
- Check any large flat area, such as a sky or a wall, for banding and blocky patches.
- Confirm the pixel dimensions are what you expected; compression should not have resized anything.
- If text matters, verify it is still legible at the size it will be displayed.
How to use it
- Drop one or more images onto the drop zone.
- Choose a target quality, or enter a maximum file size in KB.
- Pick an output format — keep the original, or switch to WebP for the web.
- Download the results and compare the reported before-and-after sizes.
Worth knowing
- Decoding and encoding both happen inside your browser; no upload occurs.
- A quality ladder is searched so target-size mode reports the quality it used.
- WebP is typically 25–34% smaller than JPEG at matched visual quality.
- EXIF metadata can add tens of kilobytes to a phone photo before any pixels are considered.
Limitations
- Compression is lossy for JPEG, WebP and AVIF — quality is spent, not merely optimised.
- Browser codec support determines the output formats available.
- Very large images are bounded by tab memory.
- Metadata is not preserved through a canvas round-trip.
- No server-side optimisation such as mozjpeg or libavif tuning is applied.