Files that get bigger

A compressor that only ever made files smaller would be hiding something. Here is the case where it does the opposite, what happens to that file, and why the count of skipped rows is the most reassuring number on the screen.

The measurement

One of the five fixtures used across this site is an image that had already been compressed hard for the web. Put through the Standard rule, this is what happened to it.

The same rule took a full-quality camera file down by seventy per cent. It is the same encoder at the same setting; what changed is the file it was pointed at.

Why it happens

A JPEG encoder spends bytes on detail. When it writes a photograph it is spending them on leaves, grain, skin texture — structure that was in front of the lens. When it writes an already-compressed JPEG it is spending them on the previous encoder’s blocking and ringing, which is structure that was not.

Those artefacts sit at exactly the frequencies the transform is worst at describing cheaply, so a second pass at a lower quality can genuinely need more bytes than the first pass at a higher one. The result looks slightly worse and weighs slightly more, which is the only outcome in this whole operation with nothing to recommend it.

• An image saved from a website, a chat app or a forum has usually been through at least one compressor already.
• A thumbnail or an avatar is small because it is small, not because it is efficient — the floor rule catches those before they are ever opened.
• A screenshot is the other flat case: 46 KB going in, and the saving is measured in tens of kilobytes on a disk that is short of gigabytes.
• A photograph exported by a previous run of this tool is the most common one of all, which is why running a compressed folder again reports almost entirely skips.

What the queue does about it

Two rules, both on by default. Anything below the size floor is never opened at all — no decode, no encode, no time spent proving that a 40 KB file is already small. Anything whose re-encode came out at or above the size it started is discarded, the original goes into the archive unchanged, and the row says how much larger the attempt was.

The consequence for the arithmetic is the point. A skipped file appears in the total at the same size on both sides, so it contributes nothing to the amount recovered and nothing to the percentage. The headline cannot be inflated by files the tool did not actually improve, which is the only way a single sentence about fifteen gigabytes is worth reading.

Questions about long jobs

How can compressing a file make it larger?

Because the second encoder is not compressing a photograph, it is compressing the first encoder's artefacts. Those blocks and ringing edges are high-frequency detail that was never in the scene, and high-frequency detail is exactly what costs bytes. The encoder faithfully spends bytes preserving damage.

Does the skip rule mean nothing happened to that file?

Nothing at all. The re-encoded version is discarded and the original is written into the archive byte for byte. The row records what the attempt weighed so the decision is visible rather than silent.

Should I turn the skip rule off?

Only to see what it was protecting you from. With it off, a folder that has been compressed before will produce an archive larger than the folder it came from, with every file slightly worse looking. That is a strange thing to want, but the switch is there because hiding it would be worse.

Why does a PNG photograph barely shrink?

Because PNG is lossless: re-deflating it rearranges the same pixels more neatly and that is all. The large saving on a PNG photograph comes from writing it as a JPEG, which is a format change — and a format change is never applied silently here. It is a Phase 2 option, off by default, reported per row when it arrives.