Picture file size reducer: what the second pass saves, and what it costs

The first pass: one photograph, six budgets

The source is a 3000 × 2000 night photograph, 689,299 bytes. Each row is one run at one byte target, JPG output. This is the baseline the second passes are measured against — and three of these rows reproduce, byte for byte, what the same file produced on earlier sessions on this site (202,286 at 200 KB, 102,087 at 100 KB, 61,310 at 60 KB, 20,385 at 20 KB), which is worth knowing: the reducer is deterministic, so a second pass measured tomorrow would land on these exact numbers.

Note where quality sits. At 200 KB it is 58.28% — the budget was generous enough to pay quality. At every target from 100 KB down it is pinned at 40.47% (41.41% at 10 KB), the floor this compressor will not go under. Below that floor the only lever left is pixels, which is why the outputs shrink from 6.00 MP to 0.26 MP while the quality figure does not move. That floor is also the reason the second passes behave the way they do below.

Same target twice: the reducer refuses, and that is correct

Take each output and run it again at the target it already meets. Nothing is re-encoded. The three rows below are the whole finding; the error columns are measured against the file fed in, which is the first-pass output itself.

This is the row that saves people from a fear they did not need to have. The folklore says re-compressing a JPEG piles damage on damage — true when a tool re-encodes unconditionally. This one does not: a file already inside the target is checked and returned, 202,286 bytes in and 202,286 bytes out, with 100% of pixels bit-identical. There is no generation loss on a pass that never encodes. The practical corollary: if you re-run a compliant file through a reducer and the byte count changes, that tool re-encoded your pixels to no purpose, and the difference is pure damage or pure bloat.

Going deeper from a file you already reduced

The interesting case: the 100 KB form field when the file in hand is the 200 KB output. Should you have compressed once to 100 KB? The table pairs each second pass with the direct run at the same target, same source photograph, same session.

Read the byte column first: the second pass buys almost nothing. 44 bytes is four ten-thousandths of the file. Even the largest gap, 220 bytes at the 10 KB target, is 2.15% — and this compressor rounds its search well inside that margin. If your reason for a second pass is bytes, there are no bytes here.

The pixel column is where the routes actually diverge, and not in one direction. At 100 KB the second pass gave up 73,310 pixels (1.78%); at 30 KB, 11,855 (1.18%); at 10 KB it handed back 623 more pixels — 623 × 416 instead of 623 × 415 — for 220 fewer bytes. The size search walks down in steps from wherever the input already is, so where it lands depends on the starting frame, not on any property of the target. That is the same non-monotone landing this site measured on the 60 KB page across starting resolutions; here it shows up across starting files.

The generation-loss bill, measured against the original

The comparisons above are against each run's own input. This table re-anchors everything to the one file that never changed: the untouched 689,299-byte original, at its full 3000 × 2000 frame. Each output was decoded, scaled back to 3000 × 2000 and compared pixel by pixel, through two independent decode paths.

The bill is remarkably flat: +0.128, +0.124, +0.111 — call it a tenth of a level per extra pass, a 3.6% to 6.5% relative worsening, at three different depths. The worst single-channel difference rose from 36 to 43 at the 100 KB route and from 56 to 60 at 30 KB. This is one extra pass, one photograph, one encoder; three extra passes would be three bills, and this page does not claim to know their sum. What it does claim: the pass you skip is the tenth of a level you keep, and the bytes you save by skipping it are the 44 to 220 above — which is to say, skipping costs you nothing that matters and saves quality that the table can see.

Why the bill is this small at all: the second encode quantizes coefficients that the first encode already flattened toward the same 40.47% floor, so there is simply not much new damage available. That sentence is interpretation, not measurement — the measured part is the three deltas, and they are the numbers to plan around. What changing format instead of re-compressing buys at the same byte count is a different page with different numbers.

What "compress image size" is actually reducing

People arrive at a reducer with any of three sizes in mind, and the tool only ever controls one of them directly. File size is the bytes — the number the upload form checks. Image size is often meant as the pixel dimensions — 3000 × 2000 becoming 1831 × 1221. Display size is neither; it is what a page or a printer does with the pixels afterwards. The order this reducer spends its levers in is quality first, pixels second, and quality has a floor: from the table above, 200 KB kept all 6,000,000 pixels and paid 58.28% quality, while 100 KB and below kept paying in pixels because quality had hit 40.47% and stopped. So whether the form says compress image size or file size, what you are really choosing is which of the two reserves — quality or pixels — the byte budget drains first, and at typical web budgets below 100 KB it is pixels. The full sweep of budgets on one page is the KB ladder.

JPEG twice: why the second encode is this cheap

Every run on this page is JPEG into JPEG — which is the honest condition for the question, since a "reduce jpg file size" second attempt always starts from a file the first attempt already encoded. Three measured facts describe what that means here. First, the same-target repeats changed nothing at all: no second JPEG generation exists to lose quality from. Second, the deeper-target passes each cost +0.111 to +0.128 mean levels against the original — real, but small next to the 1.961-to-3.110 spread the byte budget itself causes across the target range. Third, the second pass reproduced the same quality figure, 40.47%, that the direct pass chose: both encodes were working at the same floor, so the second pass was not "more compression" in the quality sense — it re-quantized an already-floor-quality file to a smaller frame. As a jpeg size reducer asked to go lower, that is the behaviour you get: same floor, smaller picture, a tenth of a level further from the original. If the file must stay JPEG and the damage budget matters, the lossless route — re-encoding the container without touching a pixel — is measured on the PNG size reducer page, whose discipline transfers even though the format does not. For the same first pass split into Y, Cb and Cr channels, see the JPEG size reducer page.

Quality as the budget: the reducer read the other way

Some people searching for an image quality reducer want the mirror operation: keep the bytes roughly fixed and spend quality. This tool does not take a quality input — it takes a byte target and reports the quality it had to spend. But the same six runs read in that direction tell you what each byte budget costs in quality on this photograph: 58.28% at 200 KB, then a wall at 40.47% from 100 KB down to 20 KB. The wall is the interesting fact. Between 200 KB and 100 KB you give up 17.8 quality points (58.28 − 40.47) for 100,199 fewer bytes; between 100 KB and 10 KB you give up essentially none, because quality cannot go lower and pixels pay instead. So if quality is what you are rationing, targets at or above the wall are where the trade actually happens, and everything below the wall is a pixel decision wearing a quality label. The second-pass bill from the table above is the same story from the other side: an extra pass spends a tenth of a level and buys back almost no bytes.

Online, in this tab: what "photo compressor online" means here

This is a photo compressor online in the literal sense — it runs in the browser — but the processing never leaves your machine. The picture is decoded, re-encoded and returned inside the tab; no request carrying it goes to a server. That is also why the same-target repeats could answer in 0 ms: the check is a local comparison against the file you already handed over, not a round trip. And it is why this page's numbers reproduce: the same input bytes with the same target return the same output bytes — 202,286 at 200 KB, 102,087 at 100 KB, 61,310 at 60 KB, 20,385 at 20 KB, matching this site's runs from previous sessions on the identical photograph. A reducer you can re-run is a reducer you can verify, and every number above is one run deep in a browser anyone can open.

How to reduce a picture file without the second pass

1. Decide the final number first. The second pass on this page happened because the first target (200 KB) turned out to be the wrong one. Check the limit before the first run, not after.
2. Set the target, drop the file, read the verdict. Bytes and dimensions are both on the result line, with the reason — quality paid or pixels paid.
3. If the file came back "already inside your limit", stop. Running it again at the same target returns the identical file; the 0 ms rows above are that check.
4. If you must go lower, go straight from the original. One pass to 30 KB sits 0.124 mean levels closer to your photograph than the same 30 KB reached through 60 KB. The bytes are the same; the pixels and the damage are not.

Questions this page gets

Does compressing a picture twice lower the quality?

By a small measured amount, and only when the second target is deeper. Against the untouched original: direct 100 KB measured 1.961 mean levels of error, the same 100 KB via a 200 KB file measured 2.089 (+0.128); 30 KB was +0.124 via 60 KB; 10 KB was +0.111 via 20 KB. Same-target repeats cost nothing — the file is returned without being re-encoded.

Why did my picture file come back the same size?

It was already inside the target. At 200 KB, 60 KB and 20 KB, compliant files came back byte-identical, dimension-identical, 100% of pixels bit-identical, with the verdict "the file was already inside your limit" and 0 ms of encoder time. Nothing ran, so nothing changed.

Is it better to compress once to the final size or in two steps?

Once. Two steps matched the bytes within 220 bytes (102,043 vs 102,087; 30,563 vs 30,716) but landed 0.111 to 0.128 mean levels further from the original, and gave up 73,310 pixels at the 100 KB route. The byte saving for all that was 44 and 153 bytes.

Will running it again make the file smaller than the target?

No. The 200 KB output run again at 200 KB returned 202,286 bytes; the 60 KB and 20 KB repeats returned 61,310 and 20,385. The reducer stops at the target rather than pushing past it — smaller means setting a smaller target, not repeating the same one.

Does "picture file size reducer" work differently on .jpg and .jpeg files?

Not on this tool. The encoder decodes the file and re-encodes the pixels, so the extension never reaches it — this site ran one photograph as .jpg, .jpeg and .jpg again on the 60 KB page and all three returned 61,310 bytes, identical byte for byte. The same path is what produced every number on this page.

Is my file uploaded?

No. Decode, re-encode and the compliance check all happen in the tab. The 0 ms same-target repeats are possible precisely because there is no round trip — the tool compares against the file it already has.

Where the numbers come from. All figures measured on 4 November 2026 with Chrome 157.0.8103.38 (headless, driven over the DevTools protocol) on Windows 11, using this site's compressor through its published interface, one run per row, each in a fresh tab. Source: a 3000 × 2000 night photograph, 689,299 bytes; first-pass outputs were saved to disk and fed back as the second-pass inputs, so every second pass started from the exact bytes the first pass produced. Output bytes were confirmed three ways on all twelve runs — the tool's report, a FileReader read of the returned blob, and the saved file on disk, all equal; dimensions two ways; the vs-original error through two decode paths that agreed to within 0.036 levels. One photograph is one sample point: a different picture will produce different deltas, though the three-way structure — nothing, then bytes-with-fewer-pixels, then a tenth of a level — is what the mechanism predicts.

Read these alongside: the KB ladder puts six single-pass budgets in one page; 20 KB is the deep end of the target range; 200 KB is where the quality floor stops biting; the PNG size reducer is the lossless alternative — bytes off the file with every pixel identical by hash; WebP is what the same bytes buy in a different format; and the JPEG size reducer splits the first-pass error into Y, Cb and Cr channels across nine budgets.