Resize image to 20 KB: ten files, ten limits, measured

The folder, and the limit each file was given

Ten files from one folder do not arrive with one limit. They arrive with ten, because each one is going somewhere different — a job application, a marketplace listing, a support ticket, a print order. So the run below assigns a limit per file, which is the thing a single "compress all" button cannot do.

What came back, file by file

Read the output columns, not the source columns. The source sizes tell you nothing about what 20 KB will give you: the 28,605-byte chart and the 926,328-byte photograph both asked for 20 KB and came back 712,125 pixels and 297,360 pixels respectively. The chart started smaller than the photograph by a factor of 32 and still ended up with 2.4 times the pixels.

Two files kept every pixel they started with. The icon was never re-encoded at all. The product shot was re-encoded and kept 2,000 × 2,000 at 76% quality, because a subject on a white background has very little for the encoder to spend bytes on — its source file was only 117,632 bytes to begin with, so a 50 KB ceiling still left room for the full frame.

Why the same 20 KB holds 33 times more pixels in one file than another

The six 20 KB outputs sorted by pixel count run from 35,721 to 1,194,285. Leave out the lossless PNG and the JPG outputs alone still span 297,360 to 1,194,285, a factor of four. The mechanism is the tool's trade-off rule, and it is the same rule for every file in the folder: hold the pixel dimensions and let quality fall, but only to 40%; below that, shrink the picture instead, because a smaller sharp picture beats a full-size mush.

That rule explains the ordering. The gradient banner and the flat chart have almost no high-frequency detail, so they hit 40% quality while still at 64% and 70% of their original dimensions. The camera photograph and the night frame are texture all the way through, so they reach the 40% floor almost immediately and then lose pixels — 24% and 32% of the original, ending at 5.9% and 10.4% of their pixel counts. Nothing about the limit changed between them.

The one number that does travel with content is bytes per pixel. At 40% quality the photograph cost 0.068 bytes per pixel, the night frame 0.033, the screenshot 0.024, the banner 0.017. If you want to predict what 20 KB will give you before you run it, that column is the predictor — not the source file size. The same measurement across five content types at a fixed 20 KB target is on the 20 KB pixel-budget page, and the PNG side of it, where lossless storage costs 0.565 bytes per pixel, is on the PNG page.

The one file that was never compressed at all

The 512 × 512 icon is 2,048 bytes and its limit was 20 KB. The tool returned it untouched: same dimensions, same 2,048 bytes, "Done in 0 ms", with the verdict line saying the file was already inside the limit and already PNG, so it was passed through. That is worth knowing before you run a folder, because it changes the order you should work in — the files that need nothing cost nothing, and running them first tells you which files are actually work.

Two conditions have to hold for that shortcut: the file must already be smaller than the target, and it must already be in the output format you selected. Ask for JPG output from a small PNG and the shortcut does not apply — the tool re-encodes, because you asked it to change the format. It also never goes the other way: a 2 KB file is not enlarged to fill a 20 KB budget, and its dimensions are not scaled up. The target is a ceiling, not a quota.

Run the same file twice and you get the same bytes

Two files in the folder were run a second time, from a fresh page load, at the same 20 KB limit. This is the whole result:

Practical consequence for a folder: if one output goes missing or gets overwritten, re-running that file reproduces it exactly. You do not need to keep a copy of every output to keep the set consistent — though you should keep the originals, since the tool writes a new file and never modifies the one you gave it.

Where the ten passes went

The ten passes took 9,615 milliseconds of encoder time in total, an average of 961 ms per file. The spread is wide: 0 ms for the untouched icon, 84 ms for the lossless PNG, 4,119 ms for the 24 MP original at 200 KB. Two things drive it, and the limit is only one of them.

Source pixels are the first. The 24 MP file took 4.1 seconds; the 5 MP photograph took 0.66. Output bytes are the second, and it is easy to miss: the same 24 MP file at a 20 KB limit took 2,090 ms rather than 4,119 ms, because the search settles on a much smaller canvas and every trial encode is cheaper. So a tight limit on a huge file is not automatically the slow case — a generous limit on a huge file is.

The format decides how many encodes the search has to do. JPG and WebP search resolution and then search quality, roughly 17 trial encodes; PNG is lossless, so quality is not a dial and the search is resolution only. The clean comparison is two files with the same 1.44 megapixels of source: the flat chart, saved as JPG, took 518 ms, and the logo, saved as PNG, took 84 ms. Same pixels in, six times the time out, purely because of the format.

At the measured average, a folder of 100 files at 20 KB is about 96 seconds of waiting — arithmetic from the ten-file average, not a measurement of 100 files. It is a coffee-break job, not an afternoon.

One limit for the whole folder: what it costs

Every bulk compressor has one target for the whole batch. That is fine if every file is going to the same form, and expensive if it is not. Two files from this folder were re-run at 20 KB to price the difference:

A page of body text at 336 × 475 is a thumbnail, not a document. So the order of work in a mixed folder matters: run each file at the limit its destination states, and only fall back to one common limit when the destination really is the same for all of them. If you are sending ten files to one form, then the form's limit is the only limit that exists, and the folder-wide approach is correct.

If the form means 20,000 bytes, not 20,480

The tool reads "20 KB" as 20,480 bytes, because it multiplies by 1,024. Many upload forms do not: they write 20 KB and enforce 20,000 bytes. The six 20 KB outputs above came back at 20,171, 20,214, 20,385, 20,393, 20,444 and 20,446 bytes — all six are over 20,000, and all six would be rejected by a form that counts decimal kilobytes.

So the safe batch setting is one step below the number the form prints. If the form says 20 KB and you do not know which convention it uses, run the batch at 19 KB: you lose 4% to 8% of the pixels and remove the entire risk of an upload rejected for being 446 bytes over. The same trap at 100 KB, where the gap between 100,000 and 102,400 is 2,400 bytes, is measured on the 100 KB upload-form page.

Doing a folder by hand, in an order that wastes nothing

1. Write the limit next to each file before you start. The limit belongs to the destination, not to the picture. A folder of ten files usually has three or four distinct limits in it, and writing them down first is what stops you re-running a file because you forgot which form it was for.
2. Run the files that are already under their limit first. They come back untouched in 0 ms, so the first pass over the folder costs almost nothing and tells you how many files are real work.
3. Then run the tight limits. 20 KB is where a picture either survives or falls apart. Finding that out on the first three files is better than finding it out on the tenth, after you have spent passes on everything else.
4. Set the output format before the target. Format decides whether quality is a dial at all: JPG and WebP can trade quality for pixels, PNG cannot, so at 20 KB a PNG only has pixels to spend. Choosing format first also keeps the file from being re-encoded when it did not need to be.
5. Read the verdict line, not just the size. "Dimensions scaled to 24%, quality 40%" and "original dimensions kept, quality 76%" are different outcomes that both say "under 20 KB". The first lost its pixels; the second lost its quality.
6. Keep the download name. Each output is named after its source with the limit appended — photo-2592x1944-20kb.jpg — so a folder of outputs documents itself and you can see at a glance which limit each one was built for.
7. Re-run only the misses. Nothing else needs a second pass, and a second pass on a file that already worked produces the same bytes anyway.

Questions this page gets

Can I resize several images to 20 KB at once?

Not in one action. The tool takes one file per pass — there is no server holding a queue, because the whole pipeline runs in the page. On the ten files above the average pass was 961 ms, so ten files is about ten seconds. Each pass keeps its own limit and its own output name, which is the advantage of doing it one at a time: a folder with four different limits is four groups of files, not one compromise.

What pixel dimensions will I get at a 20 KB limit?

Anywhere from 189 × 189 to 1,545 × 773, measured. It depends on the picture, not on the limit, and there is no width or height field to fill in — you set bytes and the dimensions follow. If you need a specific dimension, 20 KB is the wrong control: pick the dimension and accept whatever bytes it costs, or pick the bytes and accept the dimension. You cannot fix both without changing the picture. The 50 KB version of this trade-off, measured on seven starting sizes, is on the 50 KB page.

Why did my screenshot stay large while my photo got tiny?

Flat areas cost almost nothing to store and detail costs a lot. The dark UI screenshot kept 1,218 × 685, which is 40.2% of its original pixels, because most of it is one colour with straight edges. The camera photograph kept 630 × 472, which is 5.9% of its pixels, because there is texture in every square centimetre. Both were at 20 KB and both at 40% quality. The difference is entirely in what the encoder had to throw away.

Is 20 KB enough for a scanned document?

No, if someone has to read it. The A4 scan at 300 dpi came back at 336 × 475 pixels at 20 KB — legible as a thumbnail, useless as a page. At 100 KB the same file came back at 731 × 1,035 and was readable. A text-heavy page is the worst case for a byte budget: at 100 KB it cost 0.134 bytes per pixel, twice what the photograph cost, because sharp black text on white is expensive to store at any quality.

If I run the same file twice, do I get the same output?

Yes. Two files were run twice from a fresh page load and both returned identical dimensions and identical byte counts: 630 × 472 at 20,214 bytes and 968 × 646 at 20,385 bytes. Only the timing moved (657 ms against 330 ms). Re-running a file whose output you lost is safe, and the result will match the rest of the set.

Where this page stops: it is about the mechanics of running a folder — how many passes, what each pass returns, what a single folder-wide limit costs, and how the 20,000-versus-20,480 byte gap behaves. It deliberately does not re-derive the per-content-type pixel budget, which is measured here, or the ten-target ladder on a single 24 MP file, which is measured here. The two files that appear on more than one of these pages return the same numbers each time, which is the only reason to trust any of them.

Compress one image to an exact size