What comes back
Compressing a photo library gives back somewhere between nothing and nine tenths of it, and which end you land on is decided by the photographs rather than by the settings. Here is the measurement.
The measurement
Five files, each the kind of thing a real folder is full of, each written the way the device that made it would have written it. Every one was then put through this site’s Standard rule — quality 0.76, dimensions untouched — and then through the same rule with the long edge capped at 2560 pixels. Five procedurally drawn photographs, written at the settings a camera or a phone would use, then re-encoded at the Standard rule (JPEG quality 0.76) and again with the long edge capped at 2560 pixels.
| A phone photograph · 4032 × 3024 JPEG | 2.5 MB → 1018 KB · 60% smaller |
|---|---|
| A camera JPEG at full quality · 6000 × 4000 JPEG | 11.2 MB → 3.2 MB · 72% smaller |
| A screenshot · 2560 × 1440 PNG | 46 KB → 32 KB · 30% smaller |
| A scanned page · 2480 × 3508 JPEG | 1.4 MB → 555 KB · 62% smaller |
| An image already compressed for the web · 1600 × 900 JPEG | 79 KB → 88 KB · 12% larger |
| A phone photograph | 2.5 MB → 336 KB · 87% smaller |
|---|---|
| A camera JPEG at full quality | 11.2 MB → 248 KB · 98% smaller |
| A screenshot | 46 KB → 32 KB · 30% smaller |
| A scanned page | 1.4 MB → 306 KB · 79% smaller |
| An image already compressed for the web | 79 KB → 88 KB · 12% larger |
One caveat, stated because it is real: libjpeg-turbo via sharp. A browser's encoder is a different implementation and lands within a few per cent of these figures. The differences between the rows — which is what this page is actually about — hold whichever encoder writes the file.
Reading the rows
The camera file is the whole argument for doing this at all. Eleven megabytes became three with nothing but a quality change, and a quarter of a megabyte once the long edge came down — and the capped version is still larger on both axes than the screen almost anyone will look at it on.
The phone photograph does well for the same reason with less room to move: a phone has already made one economical decision before the file reaches the disk. The scan behaves like a camera file because it is one, with sensor noise standing in for foliage.
The screenshot is the interesting failure. It is a PNG, it is mostly flat colour, and it is already tiny — thirty kilobytes of saving on a file that was never the reason the disk is full. This is why the skip floor exists, and why it defaults to leaving files under a quarter of a megabyte alone.
The last row came out larger than it went in, by twelve per cent. That is not a bug and it is not rare; it is what happens when a file that has already been compressed hard is compressed again. The queue throws that result away, keeps the original and marks the row. The reasoning has a page of its own.
What to expect from your own folder
- A folder straight off a camera: expect the largest figure on this page, and expect the long-edge cap to account for most of it.
- A phone backup: expect between a third and a half at Standard, and read the skipped rows, because recent phones write HEIC and this build reports those rather than guessing at them.
- A mixed folder that has been round the internet: expect a modest total and a long list of skips. The skips are the honest part of the result.
- A folder you have already run through a compressor: expect almost nothing, and expect the queue to tell you so rather than spend an hour proving it.
The only figure worth acting on is the one from your own job, which is why the manifest is a CSV rather than a number in a badge. Run the folder, read the total, and decide about the originals afterwards.
Questions about long jobs
- Why will my folder not match this table?
- Because a saving is a property of a photograph, not of a setting. A folder of foliage and a folder of studio portraits shot on the same camera at the same quality behave differently, and a folder that has already been through a compressor behaves differently again. The table shows the shape of the answer; the manifest from your own job shows the answer.
- Which single change saves the most?
- Capping the long edge, by a distance, on anything that came out of a camera. In the measurements below it takes a full-quality camera file from eleven megabytes to a quarter of one — an order of magnitude more than the quality setting managed on its own. It is also the only part of the rule you cannot reverse from the output.
- Does compressing twice make a photograph worse?
- Yes, and measurably so on the second pass and every pass after it. Each re-encode quantises what the previous one already quantised. The skip rule limits the damage — a file that has been through this before usually comes out larger and is discarded — but the right habit is to keep the originals and re-run from them rather than from a compressed set.
- Are these figures from real photographs?
- They are from drawn ones. Five fixtures are generated from a seeded routine so that anyone can produce the identical files and check the numbers, which is not true of a personal photo library. They carry the structure that matters — gradients, hard edges, sensor noise, fine repeated detail — because that structure is what a compressor responds to.