Image Compressor
Compress and resize images in your browser without uploading anything, with a live quality comparison so you can see what you are trading away.
Resize first. It beats the quality slider, and it is free.
Pixel count grows with the square of the dimensions, which makes scaling a far blunter instrument than it feels like. Reducing the width by a quarter does not remove a quarter of the data:
| Scale | Dimensions | Megapixels | Data removed |
|---|---|---|---|
| 100% | 4000 × 3000 | 12.00 | — |
| 75% | 3000 × 2250 | 6.75 | 43.8% |
| 50% | 2000 × 1500 | 3.00 | 75.0% |
| 25% | 1000 × 750 | 0.75 | 93.8% |
Halving the width removes 75% of the pixels. And for most images that is not a loss at all, because those pixels were never going to be displayed. A 12-megapixel photo is 4000 × 3000; a 1080p screen shows 2.07 megapixels, so the photo carries 5.8 times more detail than the screen can render.
| Display | Resolution | Megapixels | Photo overshoots by |
|---|---|---|---|
| Phone | 1170 × 2532 | 2.96 | 4.1× |
| 1080p laptop | 1920 × 1080 | 2.07 | 5.8× |
| 4K monitor | 3840 × 2160 | 8.29 | 1.4× |
Resizing that photo to 1920 wide discards 77.0% of the data and costs the viewer nothing, because the browser was going to throw those pixels away during rendering anyway. Doing it before upload just means they are not downloaded first.
The common mistake is the opposite order: leave the photo at full resolution and pull the quality down to compensate. That trades detail everywhere for size, and the artefacts land in exactly the areas a viewer looks at. Resize first, keep quality high, and you get a smaller file that also looks better. Reach for the quality slider only once the dimensions are already right.
Half the colour is already gone before you start
JPEG stores brightness and colour separately, and almost always keeps colour at a quarter of the resolution — one colour sample per 2 × 2 block of pixels. That is the "4:2:0" in an encoder's settings, and it is the default nearly everywhere.
| Scheme | Samples per pixel | Data removed | What it does |
|---|---|---|---|
| 4:4:4 | 3.00 | 0.0% | Full colour resolution |
| 4:2:2 | 2.00 | 33.3% | Colour halved horizontally |
| 4:2:0 | 1.50 | 50.0% | Colour halved both ways — the usual default |
Half the data, at the default setting, and almost nobody notices — because the eye resolves far less colour detail than brightness detail. Every scheme keeps one full brightness sample per pixel; it is only the colour that gets thinned, which is why the loss is so hard to see.
There is one place it becomes obvious: sharp edges between saturated colours. Red text on a blue background is the classic failure, because the edge is almost entirely a colour transition with little brightness change, and colour is the channel that was thrown away. That is the real reason screenshots of code and text should be PNG rather than JPEG — not "JPEG is lossy" in the abstract, but that this specific loss falls exactly on the thing a screenshot is made of.
How to use
- Choose your images.
- Set the quality and any resize dimensions.
- Compare the result against the original before saving.
- Resize before compressing — it saves far more.
Frequently asked questions
What saves the most file size?
Resizing, by a wide margin. Halving an image's dimensions removes three quarters of the pixels, which dwarfs anything quality adjustment achieves. Most images on the web are served far larger than they are displayed, and fixing that is the single biggest win available.
What quality setting should I use?
Somewhere around 75 to 85 for JPEG is usually indistinguishable from the original at normal viewing size while cutting file size dramatically. Below about 60, artefacts become visible in smooth gradients and around sharp edges. The right answer depends on the image, which is why comparing matters.
Is JPEG compression reversible?
No — it is lossy, and the discarded information is gone permanently. Compressing an already-compressed JPEG compounds the damage, which is why repeatedly saving the same file degrades it visibly. Always work from the original rather than from a compressed copy.
When should I use PNG instead?
For images with sharp edges, flat colour, text or transparency — screenshots, logos, diagrams. PNG is lossless, so it keeps those crisp where JPEG produces halos around edges. For photographs, PNG produces very large files for no visible benefit.
What about WebP and AVIF?
Both compress substantially better than JPEG at comparable quality — WebP by roughly a quarter to a third, AVIF more still. WebP has broad support now; AVIF is newer with support that is good and not quite universal. For the web, serving WebP with a JPEG fallback is a common approach.
Does my image get uploaded?
No. Compression runs entirely in your browser, so nothing is sent to a server. That matters for personal photographs and for client work, and it is a real difference from most online compressors.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.