What happens when a large photo must reach 20 KB

Every figure here came from driving the real page in a real browser. Chromium opened the 20 KB page, picked the sample through the file input, pressed the button and caught the download; the sentence quoted further down is the one it read off the screen. Nothing in the run calls the compressor directly, because a number produced that way describes a module rather than the thing a visitor uses.

The build and the machine: commit b1db35c on branch feat/seo-growth-system, Chromium 151.0.7922.34, Node v20.20.2, on an Apple M1 Pro running darwin 25.5.0 arm64 with 8 cores, serving a production build at http://127.0.0.1:3911.

• Build what ships, because a development build measures the wrong bundle: npm run build
• Serve it: npx next start -p 3910 — this run answered on port 3911, which BENCH_URL selects
• Drive it from a second terminal, leaving the build alone while it runs: npm run bench

Three caveats travel with these numbers. The sample is a synthetic photograph-like scene drawn by a seeded generator and committed to the repository, not a photograph anybody took, and it is chosen to give an encoder grain and gradients to argue with. Times come from one machine in one thermal state, and this one was busy — the one-minute load average was 7.9 across 8 cores when the run began — so read the seconds as an upper bound. Bytes, dimensions and quality settings are deterministic for a given build; the seconds are not.

The two quality scores are computed over BT.601 luma with both sides decoded by the same library, so a browser codec and the reference decoder cannot disagree their way into looking like a quality difference. SSIM here uses an 8×8 uniform window and is not the multi-scale variant, so a figure from this page is not comparable with a paper reporting MS-SSIM.

The ceiling is a byte count, but the thing that decides the outcome is how many pixels are sharing it. The sample arrived carrying 1.84 bits for each of its 1,707,200 pixels. Holding every one of them under 20,480 bytes would have left 0.09 bits apiece — one bit shared between 11 pixels — and no encoder turns that back into a picture.

What the page settled on instead was 0.88 bits for each pixel, bought by removing 89% of them. Those two lines are the whole trade: the byte count landed almost exactly where it was asked to, and the pixel count did all of the moving.

Two levers, spent in a fixed order. Quality goes first and halts at 50, because further down a JPEG shows the blocking and ringing nobody wants on a document. The width and height only start moving once an encode at that floor is still over the line.

Each step then takes 20% off both sides, and — this is the part that is easy to get wrong — every step resamples from the original file rather than from the step before it. Stacking 8 rounds of filtering on top of each other comes out visibly softer than one round straight to the same size, for identical dimensions and identical bytes.

524 is exactly the 5th rung of that ladder, so 5 shrinks ran before anything fit. The quality that finally won was 68, which is above the floor, and that is the search climbing back: the floor only binds while the picture is too big. At 524×350 an encode at 50 fit with room to spare, so the search spent the room on looking better.

The walk stops after 8 steps, or when the short side would fall under 32 pixels, or when it runs out of time. This one needed 5 of the 8 and finished in 1.83 s.

Under the finished picture it printed: "Asked for 20 KB — landed on 19.64 KB at quality 68 after shrinking the picture from 1600×1067 to 524×350. Nothing was resized silently: this is the Shrink to fit policy you chose."

Two things in that sentence repay a second look. It names the size it stopped at, because a page that quietly hands back a smaller picture gets found out by the form rather than by you. And 19.64 KB is 20,111 bytes: a kilobyte is 1,024 bytes here, exactly as it is in the file size your computer shows you.

So the file that met a 20 KB ceiling sits above a round twenty thousand. A field written against the round number will refuse it, and the fix is to set the figure a little lower and run it again rather than to argue with the form.

Not at every ceiling, and the second measurement says so plainly. The same source was taken to 100 KB twice: once by resizing to 1200 px and compressing after, once by compressing the full 1600 px frame and downscaling the result to 1200 px afterwards. Both were scored against one reference, the source at 1200 px, which is what somebody displaying the picture at that width would actually see.

The full-size lane won on both scores, by 3.08 dB and 0.0100 SSIM, and it did it at the lower quality setting of the two — 66 against 85. The explanation the numbers point to is the downscale at the end: it averages several encoded pixels into every displayed one, and averaging hides compression noise. Resizing first hands the encoder fewer pixels to spend the budget on, but buys none of that help afterwards.

Read that narrowly. It is one sample, one ceiling, one machine, and a drawn scene rather than a photograph — not a statement about JPEG and not a statement about every target. At 20 KB the same source could not stay at full size at all, which is the far end of the same dial. Shrinking is what a tight ceiling forces, not a trick that improves a loose one.

Settle the pixel box before the byte count when the field states both. The fit policy chooses a size in order to satisfy the ceiling and knows nothing about the box the form wanted, so compare the width printed under your result against what was asked for before you attach anything.

Crop before you compress when the subject is small in the frame. Margin costs the same bits as a face does, and at this ceiling there are very few bits to spend on anything nobody will look at. Cutting the frame down first is often the entire fix, and it leaves the size of what remains under your control instead of the policy’s.

And start looser if the requirement allows it. A ceiling that the quality dial can reach on its own leaves the width and height untouched, which is the outcome to prefer whenever the form will accept it; coming back down later costs you nothing but the second run.

• Compress to 20 KB — Run the same 20 KB ceiling on your own file and read the size it stopped at.
• Compress to 50 KB — Try the looser ceiling first, where the quality dial often gets there with the pixels intact.
• Resize Image — Pick the width yourself, rather than letting the fit policy choose it for you.
• Signature Resizer — Fit a scanned signature to a pixel box and a byte ceiling in a single pass.