Why your image won't get smaller
Every compressor claims a percentage. Here is the part they usually leave out: a second pass over the same photo can only remove what the first pass already removed. We ran the numbers on three test photographs, and they shrank by 115 bytes in total — less than one thousandth of one percent. If you came here because your image is still too large, the reason is almost never that the tool failed. It is that something else is holding the file up.
- Nothing is uploaded
- Numbers measured here, not quoted
- No file-count limit
- Keeps your original if it can't win
Drop your images here
or paste from the clipboard · ⌘V / Ctrl+V works too
JPG · JPEG · PNG · WebP · AVIF · HEIC · GIF · BMP — no file count limit
Compression settings
Applied to every imageAuto measures each image: it encodes a test pass at several quality levels, scores the result against the original, and keeps the smallest file that still clears a ~40 dB fidelity floor.
Advanced options
Need exact dimensions or a centre crop instead of a cap? The batch image resizer does that.
Auto applies a halo-free unsharp mask only when an image is scaled below 82%.
Generated in your browser by a synth — no audio file is downloaded, and it stays silent when a batch finishes in a couple of seconds.
WASM codecs are fetched from a public CDN on first use and give slightly smaller files. Every fallback still works offline.
Results
The second pass, measured
Three photographs were taken from this project's benchmark corpus — 2400 × 1600 pixels each, the shape of output a modern camera produces. Each one was encoded once, decoded back into pixels, and encoded again, twice over. Same encoder, same setting, same quality, every time. Quality was scored against the original photograph on every round, so a round that quietly degraded the image would show up as a falling number rather than hide behind a file that looked smaller.
| Test photo | First pass | Second pass | Third pass | Total change | Quality lost |
|---|---|---|---|---|---|
| photo-1 · 890,690 B | 362,491 B | 362,450 B | 362,399 B | −92 B | 0.03 dB |
| photo-2 · 670,873 B | 314,933 B | 314,909 B | 314,923 B | −10 B | 0.00 dB |
| photo-3 · 1,675,584 B | 691,404 B | 691,361 B | 691,391 B | −13 B | 0.14 dB |
| All three | 1,368,828 B | 1,368,714 B | 1,368,713 B | −115 B | median 0.03 dB |
One hundred and fifteen bytes. Across three photographs that the first pass had already cut from roughly 3.2 MB down to 1.37 MB. The three extra passes bought 0.008% — and cost a little quality to get. That is not a bug in the encoder. It is the arithmetic of compression catching up with itself.
Why the file stops moving
Compression works by finding patterns and encoding them once instead of many times. The first pass found every pattern the format could hold: repeated colour runs, predictable edges, the statistical bias in how your eye weighs detail. Once those are gone, the second pass is fed a file whose bytes are already close to as random as they need to be. There is nothing left to describe more cheaply.
One honest exception, because it keeps the table from misleading you: changing codec is not a second pass. Feeding an already-compressed JPEG to AVIF or WebP can still find real savings — a different encoder sees a different representation of the same pixels. The measured table on the compressor page puts AVIF between 0% and 37% better than the input on already-optimised photos, depending on the picture. The floor in the table above is specifically about re-encoding the same file in the same format at the same quality, which is the operation a "compress it again" button performs.
This is also why the number never goes to zero. A JPEG at quality 60 is lossy: the decoder may not reproduce the same bytes the encoder saw, so a round trip always costs something. Two extra passes here measured 0.03 dB and 0.14 dB — below the threshold most people can see, and still a loss. If you run a tool three times because the first two "didn't quite do it", you are paying quality for a rounding error.
What actually holds a file up
When an image will not shrink, one of four things is true. In order of how often it is the culprit:
- The format is wrong for the picture. A lossless PNG of the same pixels measured here came out 1,816,238 bytes against the source JPEG's 890,690 — 104% bigger for an identical picture. On the other photos in the same run it was 191% and 50% bigger. This is also the usual answer to "why did my compressed image come back bigger than the original": the tool changed format underneath you, or re-encoded through a canvas that widened 8-bit colour into 32-bit RGBA, adding bytes before the encoder even started.
- The pixels are the reason. A 2400 × 1600 photograph is 3.84 million pixels. Six bytes of colour data each, minus whatever the codec saves. Until you change the pixel count, the floor is standing where it is. Halving each edge quarters the pixels.
- The image is already compressed. Screenshots, saved-for-web assets, thumbnails from a CMS, images that have already been through one compressor — these often sit close to their floor before you arrive. A screenshot is the extreme case: flat blocks of one exact colour with hard edges, where nearly every pixel value is already unique, so there is almost no redundancy for any codec to remove.
- Metadata was never the problem. EXIF, GPS and embedded thumbnails can be tens of kilobytes, and stripping them is real savings — but on a well-behaved photograph it is the difference between 362 KB and 358 KB, not between 362 KB and 200 KB.
What to do instead of pressing compress again
Three levers move the number; the one you already tried does not.
- Fewer pixels. The strongest lever by a wide margin. Dropping the long edge from 2400 to 1200 removes about three quarters of the pixels, and the byte count follows the pixel count. Do this in the batch resizer, or from the resize cap in Advanced.
- A better codec. At equal measured quality, WebP and AVIF land below JPEG on photographic content — the main compressor picks between them per image rather than forcing one.
- A hard budget. If a form, portal or inbox caps you at 100 KB or 200 KB, say so in KB and let the engine work backwards from it. The compress to 100 KB, 50 KB and 200 KB pages are built for exactly that, and the compress for email page covers the attachment-limit case.
And when the honest answer is "this file cannot go lower", the tool here says so. The result row is labelled already optimal, and the save button hands back the original bytes you uploaded — not a re-encoded copy that lost quality and gained nothing. That is the difference between a compressor that tells you it failed and one that tells you there was nothing to do.
You do not have to take the floor on trust. Drop the file into the compressor above and it will report when there is nothing left to take, and keep the original when a re-encode would only cost you quality. No image is sent to a server to find that out, and running it again is not how you change the answer — a media library of files that have all hit their floor is the same problem, and it is solved per file, not by hand.
The complaints that bring people here all mean the same thing, phrased a different way each time: the image is not getting smaller, or it doesn't get smaller on the second attempt, or the file came back bigger than the original, or the second run came out bigger than before, or the last pass only came out barely smaller while it cost quality. The move almost everyone makes next is to run it again — and then to compress it again — and the byte count lands where it landed. Nothing on that path changes the pixels, and nothing changes by handing the file to a random server either: no remote service can take a floor the pixels do not allow, and it adds a wait, an account and a daily limit to a problem you can already see in this tab. The other half of the complaint is time. A media library of 2,000 photographs is not something you shrink one at a time, and that is why the compressor above works over the whole queue without an account.
How these numbers were produced
They came out of the same engine this site runs in your browser, not out of a vendor's benchmark page. Each photograph was decoded to raw pixels, encoded with the site's own encoder, decoded again, and re-encoded, with a PSNR score measured against the original frame on every round. The script that produced them is part of this project's _dev folder, and the raw output is archived next to it. If a future encoder changes the result, the table will change with it — and a number nobody can re-produce is not evidence.
Frequently asked questions
Why won't my image get smaller after I've compressed it once?
Because the first pass already removed the compressible parts. A second pass over the same file at the same setting finds almost nothing left to find, so the byte count stops moving. In a test run here, three photographs were compressed three times with the same encoder: the files went from 1,368,828 bytes to 1,368,713 bytes — a saving of 115 bytes across all three, 0.008% of what the first pass had already achieved. Nothing was broken; the file was simply at its floor.
Why did my compressed image come back bigger than the original?
Usually because the format changed underneath you, or because the original already sat in a format that compressed well. A lossless PNG of the same pixels measured here weighed 1,816,238 bytes against the source JPEG's 890,690 — 104% more for identical pixels. Some tools also re-encode through a canvas that silently expands 8-bit images to 32-bit RGBA, which adds a few bytes per pixel before any encoder runs.
Is it safe to run a compression tool twice on the same photo?
It works, but it is not free. Each pass decodes the file and re-encodes it, which costs a little quality every time even when it costs no bytes. Over two extra passes on the same three test photos the peak quality loss measured 0.14 dB, and the median was 0.03 dB — small, but you paid for it and got nothing back.
What if I really need the file smaller and it isn't shrinking?
Change one of the three things that actually move the number: fewer pixels, a different codec, or a lower quality target. Dropping the long edge from 2400 to 1200 removes roughly three quarters of the pixels and therefore most of the bytes; switching from JPEG to WebP or AVIF at equal measured quality typically lands a further 20-30% lower; and a fixed budget such as 100 KB or 200 KB is reachable directly. Re-running the same operation is the one lever that never moves.
Why does a screenshot stay huge when a photograph shrinks easily?
Because a photograph compresses well and a screenshot does not. A photo is a smooth gradient of millions of similar colours, which a codec can predict and then encode once. A screenshot is flat blocks of exactly one colour with hard edges — every pixel value is already unique, so there is almost no redundancy to remove. That is why a 2 MB photograph and a 2 MB PNG save-for-web screenshot can behave completely differently in the same tool.
Should I export my photos as PNG to make them smaller?
Only for graphics that need to stay sharp — logos, charts, icons, text. For photographs PNG is the wrong way round: in this test the same pixels came out 104%, 191% and 50% larger in bytes than the JPEG they started as. A PNG is lossless by definition, so it must carry every pixel exactly; it has no quality setting to turn down.
Does the tool here tell me when it can't make my image smaller?
Yes, and it hands you your own file back rather than a worse one. When a re-encode would not make the file smaller, the result row is labelled already optimal and the save button downloads the original bytes you uploaded, unchanged — not the larger re-encoded copy.