Guide
Why re-saving a JPEG can make it bigger
Compressing something twice ought to make it smaller twice. With JPEG it frequently does the opposite, and the amount is not small: measured on five photographs, a second pass at quality 92 added about 27% to every one of them.
The measurement
Five photographs, from a 26-megapixel camera file down to a small phone snapshot, were re-encoded at their original pixel size and at a range of quality settings. Nothing was resized, cropped or edited. This is the "just save it again, a bit smaller" operation and nothing else. The encoder is the one built into the browser, the same one this site uses.
| Original | Size | q96 | q92 | q85 | q80 | q75 |
|---|---|---|---|---|---|---|
| 6240 × 4160, camera | 8942 KB | 6094 | 3729 | 2467 | 2007 | 1680 |
| 2160 × 2880, phone | 2945 KB | 1514 | 1217 | 1057 | 995 | 943 |
| 2316 × 3088 | 1474 KB | 1814 | 1489 | 1247 | 987 | 596 |
| 1512 × 2016 | 1023 KB | 1249 | 1044 | 884 | 740 | 519 |
| 1503 × 2001 | 686 KB | 838 | 699 | 602 | 503 | 367 |
Sizes in KB. Highlighted cells came out larger than the file that went in.
The first two files shrank at every setting. They came out of a camera and a phone with very little compression applied, so there was room to take some away. The last three grew: by 1 to 2% at quality 92, and by 22 to 23% at quality 96. Those three had already been compressed once, somewhere upstream, and asking for quality 96 was asking for more fidelity than the file contained.
Why asking for more quality costs more bytes
JPEG works by cutting each image into 8 × 8 blocks, describing each block as a sum of wave patterns, and then rounding those descriptions off. The quality setting decides how coarsely it rounds. Low quality rounds hard, throws away most of the fine detail, and needs few bytes to write down what is left.
The catch is that the encoder has no idea what the previous pass threw away. It sees only the pixels it is given. When those pixels already contain the blocky, ringing, slightly banded output of an earlier compression, a high quality setting reproduces the blocks and the ringing in full detail, spending real bytes to preserve damage that was never in the photograph.
Compression artefacts are sharp edges, and sharp edges are exactly what JPEG finds expensive. A high-quality pass over a low-quality image is the worst of both: you pay a premium to store the flaws, and you get none of the detail back.
The case that actually bites people
The table above uses originals. The more common situation is a file that has already been through the mill once: downloaded from a messaging app, exported from a website, saved out of a document. To reproduce that, each of the five photographs was first reduced to 1200 px at quality 75, which is roughly what such a pipeline does. Then that result was re-encoded:
| File after one pass | q92 | q85 | q80 | q75 |
|---|---|---|---|---|
| 99.6 KB | 127.1 +28% | 113.5 | 104.6 | 99.6 |
| 314.7 KB | 400.5 +27% | 352.7 | 330.8 | 314.6 |
| 96.8 KB | 124.8 +29% | 112.4 | 101.8 | 96.6 |
| 208.5 KB | 264.2 +27% | 234.3 | 217.9 | 208.4 |
| 183.3 KB | 233.3 +27% | 207.6 | 193.4 | 183.3 |
Every file grew, and the figure is strikingly consistent: between 26.7% and 28.9%. There is nothing special about these photographs. It is the arithmetic of asking quality 92 to describe a picture that holds only quality 75 worth of information.
Re-saving at the same quality is nearly free
The folk wisdom is that a JPEG degrades a little every time it is opened and saved, like a photocopy of a photocopy. That turns out to be false in the case that matters. The 1600 px version of one photograph was encoded at quality 80, decoded, re-encoded at quality 80, ten times over:
| Pass | 1 | 2 | 3 | 5 | 10 |
|---|---|---|---|---|---|
| Size | 197.8 KB | 197.9 | 197.8 | 197.8 | 197.8 |
| Difference from the original pixels | 2.38 | 2.38 | 2.38 | 2.38 | 2.38 |
Mean absolute difference per pixel, 0–255 scale.
All of the loss happens on the first pass. After that the file is a fixed point: the pixels it decodes to are already the pixels that survive that quantisation, so encoding them again changes nothing. The photocopy effect is real only when something moves between passes.
And that is the important caveat. The 8 × 8 grid has to land in the same place each time. Crop by a few pixels, resize, rotate by anything other than a multiple of 90°, and the blocks no longer line up with the ones already baked into the picture, and each pass then really is a fresh, lossy encode.
So when is re-encoding the right move?
Four reasons, all of them legitimate:
- The format is wrong. A PNG, HEIC or WebP that has to become a JPEG for an upload form has no choice.
- The dimensions are wrong. Removing pixels is the honest way to make a file smaller, and it requires a new encode anyway.
- The metadata has to go. Stripping the GPS coordinates out of a photograph means rewriting the file.
- There is a hard ceiling to meet. A form that refuses anything over 200 KB does not care about any of the above.
What is never a good reason is "it feels big". If you have no target, re-saving buys you nothing and may cost you a quarter of the file size again.
What this tool does about it
It refuses the pointless pass. If your file is already a JPEG, already fits the size you asked for, and you have not asked for a change in dimensions, it is handed straight back untouched. The result card says already fits and the download is your own bytes.
That guard exists because of a measurement: before it was added, a 348 KB file that already satisfied the limit came back at 474 KB. The tool had done exactly what it was asked and made the problem worse.
The same check runs one level deeper, inside the search: if the best re-encode that fits is still heavier than the original, the original wins.
Need to hit an exact limit? Compress to a file size →