Compress Image
Compress Image makes a photo file smaller — either at a quality you pick, or down to a size you name, like 100 KB. What the preview shows is the real result, not a shrunken copy of the original, so you can see exactly what a setting costs the picture before you download anything.
Drop images here
or drop anywhere on this page · Choose files · 100 MB
How does Compress Image work?
Image compression is a trade you make on purpose: throw away detail the eye is least likely to miss, in exchange for a file that transfers faster. What separates a good result from a bad one is not the tool — it is knowing which knob to turn, and being able to see the cost before you commit.
What “quality” actually controls
In JPEG, quality scales the quantisation table. The encoder converts each 8 × 8 block of pixels into frequency coefficients, then divides them by that table and rounds — the rounding is where information is permanently lost. A high number divides gently and keeps fine detail; a low one divides hard, and whole coefficients collapse to zero. That is why artefacts appear as blocks and as ringing around sharp edges: the lost coefficients were the high frequencies that made the edge sharp.
WebP and AVIF work differently in detail — they are derived from video codecs and predict each block from its neighbours before coding the difference — but the shape of the trade-off is the same, and so is the advice below.
Useful settings
Between 0.75 and 0.85, JPEG is visually indistinguishable from the original for almost any photograph, at roughly a third of the size. Above 0.95 the file grows steeply for nothing a person can see. Below 0.6 the artefacts are obvious in flat areas — a clear sky is where they show first. Text and line art are the exception: any lossy setting smears the edges, and those images belong in PNG or WebP's lossless mode.
Compressing to a target size
There is no way to ask an encoder for “about 200 KB”. The resulting size depends on the picture — a flat screenshot at quality 0.9 might be 40 KB where a detailed photograph at the same setting is 900 KB — so the only honest method is to encode, measure, and adjust. This tool binary-searches the quality range, which lands inside your budget in about seven encodes rather than the twenty a linear walk needs.
The search is deliberately biased downwards: the result returned is always the best one that fit, never the nearest one that did not. A tool asked for “under 200 KB” that hands back 214 KB has failed at the one thing it was asked to do — usually because the upload form on the other end will reject it.
When quality is not the right lever
If an image will be displayed 800 pixels wide, storing it at 4000 pixels wide costs twenty-five times the pixels and buys nothing. Resolution is a much blunter and more effective saving than quality, and it is the first thing to try when a target size is out of reach — which is why there is a maximum-width box here as well as a quality slider.
Why re-compressing a JPEG twice is a bad idea
JPEG compression is not idempotent. Each pass re-quantises coefficients that were already quantised, on a block grid that may no longer line up, so artefacts accumulate — this is generation loss, the same effect as photocopying a photocopy. Compress from the original whenever you have it, and choose a lower quality once rather than a moderate quality three times.
Where the work happens
In this tab. The decode uses createImageBitmap and the encode uses the browser's own canvas.toBlob, which are the same C implementations your browser uses to display and save images anywhere else. Nothing is uploaded, and the page's Content-Security-Policy sets connect-src 'self', so an upload would be refused by the browser rather than merely not attempted.
Input
holiday.jpg — 4.2 MB 4032 x 3024, quality 0.75 max width 1600
Output
holiday.jpg — 268 KB 1600 x 1200 -94%
What options and edge cases does Compress Image support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Quality 0.9–1.0 | quality | — | Visually lossless and large. Worth it only when the image will be edited again afterwards. |
| Quality 0.75–0.85 | quality | 0.75 | Indistinguishable from the original for most photographs, at roughly a third of the size. The default for a reason. |
| Quality 0.5–0.7 | quality | — | Visible artefacts in flat areas such as sky. Acceptable for a thumbnail, not for a hero image. |
| Target size | KB | 200 | Binary-searches quality for the best result that fits. Always lands under the budget, never over. |
| Max width | pixels | none | Scales down first, preserving aspect ratio. Never enlarges. The strongest saving available. |
| Same as source | format | default | Keeps JPG as JPG and PNG as PNG. Note that a PNG re-encoded as PNG often grows. |
| WebP | format | — | Typically 25–35% smaller than JPEG at the same visible quality, with transparency. Supported by every current browser. |
| AVIF | format | — | Smaller again than WebP, especially at low quality. Encoding is slow and unavailable in some browsers, which this page detects rather than assumes. |
Frequently asked questions
What quality setting should I use?
0.8 for anything that matters and 0.75 for the web generally. Both are visually indistinguishable from the original on a photograph while cutting the file to roughly a third. Going above 0.95 grows the file steeply for detail nobody can see; going below 0.6 produces blocking in flat areas like skies and halos around text. If the image is a screenshot or a diagram, quality is the wrong lever entirely — use PNG or lossless WebP.
Why did my PNG get bigger instead of smaller?
Because PNG is lossless, so a quality slider does nothing, and re-encoding it just re-runs the same compression with different tuning than whatever wrote it originally — often less aggressive tuning. If a PNG is large it is usually a photograph that should not have been a PNG in the first place: convert it to JPEG or WebP and it will typically fall by 80% or more. PNG is the right format for screenshots, logos and anything with sharp edges or transparency.
Can it hit an exact file size?
It can get under one, which is what the requirement usually is. Encoders take a quality setting, not a size, and the size that results depends entirely on the picture — so this tool encodes, measures, and adjusts, binary-searching the quality range until it finds the best result that fits. It never returns something over your budget. If it cannot fit even at the lowest quality, it says so and suggests reducing the dimensions, because at that point pixels rather than quality are the problem.
Is JPEG, WebP or AVIF the right output?
WebP is the best default now: 25–35% smaller than JPEG at the same visible quality, supported by every browser in current use, and it handles transparency. JPEG when the recipient is a system you do not control — an old CMS, a printing service, an email client. AVIF when size matters more than anything and you know the destination accepts it; it beats WebP by another 20–30%, but encoding is slow and not every browser can even produce it, which this page checks before offering it.
Does compressing an image twice make it smaller?
It makes it worse. JPEG compression is not idempotent: the second pass re-quantises coefficients that were already quantised, on a block grid that may no longer align, and the damage accumulates. This is generation loss — the same reason a photocopy of a photocopy degrades. Always compress from the original, and pick a lower quality once rather than a moderate quality repeatedly.
Are my photos uploaded anywhere?
No. The decode and the encode both use your browser's own image pipeline, running in this tab, and the files never leave your machine. You can verify it rather than believe it: open DevTools, watch the Network panel, and compress a batch — nothing is sent. The page is also served with connect-src 'self', so the browser would block an upload even if some future bug attempted one.
Is metadata like GPS location removed?
Yes, as a side effect of how this works. The image is decoded to pixels and re-encoded from them, and EXIF blocks — camera model, timestamp, GPS coordinates — are not carried across. Orientation is the one tag that is honoured rather than dropped: it is applied to the pixels during decoding, so a photo taken sideways comes out the right way up rather than losing the tag and turning on its side.