Guide
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 a measurement on synthetic test images.
The measurement
Five synthetic images, drawn by a script to stand in for the kinds of file a real folder is full of — not photographs — each written the way the device that made it would have written it, and encoded on a server with libjpeg-turbo rather than in a browser. 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, which opens here only in a browser that decodes HEIC itself (Safari); elsewhere those rows say so.
- 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.