Guide

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.

An already-efficient JPEG, Standard rule · measured 2026-09-19
Went in at	79 KB
Came out at	88 KB
Difference	12% larger

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.

What happens to a PNG here?

Two encodes, and the smaller one wins. The lossless pass re-deflates the same pixels with the scanline filters tried properly, which is all a lossless format can ever buy. The second pass reduces the palette to the number of colours the quality position names, which on a photograph saved as a PNG is usually the difference between four megabytes and one. A picture that already holds fewer colours than that comes out of the palette pass no smaller, so it keeps every colour it had, and the row says so rather than claiming a reduction that did not happen. Writing a PNG out as a JPEG would save more again, but that is a format change and a format change is never silent here.