Reduce image size in KB

One 3000 × 2000 photograph, six byte targets

The table is the answer. One JPEG — 689,299 bytes, 3000 × 2000, 6.00 megapixels — went through this compressor nine times, once per target, each run on a freshly loaded page. Six of those targets are tabulated here; 300 KB, 2 MB and 5 MB are measured in the tier list further down. Nothing in the table is estimated from a formula: bytes, dimensions and quality are what the tool returned, and the error column is measured afterwards by decoding the output and comparing it with the source at full size.

A kilobyte is 1,024 bytes here, so the 20 KB target is 20,480 bytes and the 1 MB target is 1,048,576. If your form counts 20 KB as 20,000 bytes it is 480 bytes stricter than this tool, and the same file can pass one and fail the other. Mean error is the average absolute difference per colour channel on a 0–255 scale; 0 would be a byte-for-byte copy. "Smaller than source" is 689,299 divided by that row's output, so 1.00× means the file came back untouched.

Every run landed under its cap, and the spare bytes shrink with the budget: 95 at 20 KB, 220 at 50 KB, 313 at 100 KB, 2,514 at 200 KB, 981 at 500 KB. The 1 MB row has 334,701 bytes spare for a different reason — nothing was encoded at all. Relative to the source, the six targets cut it to 33.81×, 13.52×, 6.75×, 3.41×, 1.35× and 1.00× its original size, which is 97.04%, 92.60%, 85.19%, 70.65%, 25.86% and 0.00% less data.

Three of the six targets do not change quality at all

20 KB, 50 KB and 100 KB all came back at quality 40.47% — the same number to two decimal places, because that is the floor this compressor will go to. Once the floor is reached the only variable left is pixel count: 0.63, 1.82 and 4.11 megapixels. So on this photograph the difference between a 20 KB limit and a 100 KB limit is 6.57× the pixels and not better quality — 968 × 646 against 2482 × 1655, both at 40.47%. The error does improve with the budget, because a smaller picture is being compared against a smaller copy: mean error falls from 2.701 to 2.259 to 1.961, a 27.4% reduction from the 20 KB row to the 100 KB row, while quality is identical.

That is the practical answer for anyone choosing a tier: below roughly 146 KB on a 6-megapixel photo, a bigger budget buys resolution, not fidelity. The 100 KB run is 4.11 megapixels; the 200 KB run is the first one that keeps all 6.00.

Bytes per pixel: what each target costs, and where the cost stops falling

Dividing each output by the pixels it actually contains gives the price of a target in bytes per pixel: 0.03260 at 20 KB, 0.02799 at 50 KB, 0.02485 at 100 KB, then 0.03371 at 200 KB, 0.08517 at 500 KB and 0.11488 at 1 MB.

The first three fall as the budget rises — 0.03260 at 0.63 megapixels against 0.02485 at 4.11 — because all three are pinned at the same 40.47% floor. The figure then jumps back up at 200 KB, and that jump is the floor releasing: the encoder is no longer limited to spending quality, so each extra byte buys fidelity rather than area. This is the reason a bytes-per-pixel number is only comparable between two runs that are both at the floor; across the floor it measures a different trade. The numbers above are measured; the explanation for why cost per pixel falls as an image is resampled down is my reading of the pattern, not something I tested separately.

Where the pixel loss begins: an extrapolation, not a measurement

There is no run at 130 KB or 160 KB in the table, so the exact crossover is not measured here. It can be extrapolated from the 100 KB row, which is the last one still at the floor, and that row is already a scaled image — 2482 × 1655, not 3000 × 2000. Dividing its bytes by its own pixels gives 102,087 ÷ 4,107,710 = 0.02485 bytes per pixel at 40.47% quality. Multiplying that per-pixel cost by the full 6,000,000 pixels gives 0.02485 × 6,000,000 = 149,100 bytes, or 145.6 KB — the budget at which, if the cost per pixel held constant, this photograph would just fit at the floor with every pixel intact.

Treat that figure as arithmetic, not a result. The per-pixel cost comes from an image that has already been resampled down, and applying it to the full pixel count assumes resampling does not change the cost per pixel — which it usually does, in the direction of making it lower. The two measured rows either side of it are what actually constrain the answer: 100 KB scaled to 4.11 megapixels, 200 KB kept all 6.00 at quality 58.28%.

Tier by tier

compress image to 20kb: 968 × 646, quality 40.47%

Choose it for avatars, list thumbnails and email signatures — pictures that never display wider than a couple of hundred pixels. It is the tightest tier here and the only one where the softness is visible without a side-by-side: 20,385 bytes from a 689,299-byte source (33.81× smaller), 968 × 646, the 40.47% floor, mean error 2.701, worst pixel 65, and 29.63% of pixels moved by more than 4 levels. The full ladder from this tier upward, on a different photograph, is on compress image to 20kb.

compress image to 50kb: 1653 × 1102, same 40.47%

Choose it for grids, forum posts and comment images, where 1.8 megapixels is enough to read a face or a product but 4 megapixels would be wasted: 50,980 bytes, 1.82 megapixels, quality still 40.47%. The bytes are 2.5× the 20 KB run and the pixels 2.9×, so the extra budget goes almost entirely into area. Mean error 2.259, worst pixel 54, and the share of pixels moved by more than 4 levels only falls from 29.63% to 23.72%. This run took 3.00 s, the longest of the nine. Content types at this budget: compress image to 50kb.

compress image to 100kb: 2482 × 1655, still the floor

Choose it for body copy — a blog illustration, a phone screenshot, a light product shot — at 4.11 megapixels, the last tier where the floor still binds: 102,087 bytes, quality 40.47% for the third time in a row, mean error 1.961, worst pixel 36, and only 0.10% of pixels off by more than 16 levels. It is also the row the crossover above is extrapolated from. What a lossless source does at this same budget is a different arithmetic entirely: compress image to 100kb.

compress image to 200kb: every pixel kept, quality 58.28%

Choose it for article headers, CMS uploads and anything shown at full width on a desktop — it is the default on this page because it is the first tier that stops cutting: 202,286 bytes, all 3000 × 2000 pixels, quality 58.28% (17.8 points above the floor), mean error 1.552, worst pixel 26, 7.27% of pixels bit-identical. The jump from 100 KB costs 98% more bytes and returns 46% more pixels plus those 17.8 points. The same file at nine budgets: compress image to 200kb.

compress image to 300kb: all pixels kept, quality 76.09%

Choose it for pictures whose subject has to survive a close look — a product detail, a portfolio thumbnail, a crop that will be studied rather than glanced at: 297,719 bytes (2.32× smaller), still all 3000 × 2000, quality 76.09%, mean error 1.135, worst pixel 22, 25.37% of pixels identical, 1.84 s. The nine-budget ladder behind this row is on compress image to 300kb.

compress image to 500kb: every pixel kept, quality 81.25%

Choose it for a hero image, a photography preview or a marketplace main shot — anything that has to survive being opened full-screen: 511,019 bytes (1.35× smaller), 3000 × 2000, quality 81.25%, mean error 0.997 — under one level per channel — worst pixel 17, 28.15% of pixels identical. Against the 200 KB run this is 2.5× the bytes for 35.8% less error and no extra pixels. The eleven-budget version of the same flattening: compress image to 500kb.

compress image to 1mb: nothing to do, the file already fits

Choose it for large previews that must still open instantly and look untouched at 100% — and note what happened here: the source is 689,299 bytes and the target is 1,048,576, so the tool returned it unchanged, 100% of pixels identical, mean error 0, in 0.36 s, with 334,701 bytes of the cap unused. There is no quality number because nothing was re-encoded. Where this target really binds, on a much larger source: compress image to 1mb.

compress image to 2mb: the cap was never reached here

Choose it for high-resolution screenshots, design exports and camera files that a 1 MB cap would visibly damage. On this source the 2,097,152-byte cap was not binding either: 689,299 bytes came back untouched, 1.00× the original, mean error 0, 0.38 s. A tier that does nothing is the correct answer for a file that already fits — re-encoding would spend quality for no byte gain. What the 2 MB ceiling does to a 54-megapixel photo: compress image to 2mb.

compress image to 5mb: the top of the ladder, still nothing to do

Choose it for camera originals, scanned artwork and anything you would rather not touch unless a platform forces it: 5,242,880 bytes of cap against a 689,299-byte file, so again nothing happened — 1.00×, mean error 0, 100% of pixels identical, 0.34 s. Above roughly this point a byte target stops being a compression question and becomes a "is this even too big" question. The measured answer at this ceiling: compress image to 5mb.

Questions that come up when the limit is a number of KB

Is 20 KB the same as 20,480 bytes?

In this tool, yes: it counts a kilobyte as 1,024 bytes, so 20 KB is 20,480 and the run above returned 20,385 with 95 bytes to spare. Plenty of forms mean 20,000 bytes, which is 480 bytes stricter. If a file passes here and is rejected there, the unit is the first thing to check — the same trap in the other direction is a 2 MB limit that is really 2,000,000 bytes.

Why does 1 MB return my file unchanged?

Because it already fits. Re-encoding a 689,299-byte JPEG to reach a 1,048,576-byte cap would spend quality to arrive at a size the file already had, so the tool passes it through instead. If your file is over the cap the same tier does encode — the difference is the input, not the setting.

Does reducing to a KB target always cut the dimensions?

No. Three of the six targets kept every pixel here (200 KB, 500 KB, 1 MB) and three did not (20, 50, 100 KB), all at the identical 40.47% floor. Whether your file keeps its dimensions depends on how many bytes per pixel it needs at that floor, which is why the same 20 KB target that cut this photograph to 968 × 646 will keep every pixel of a flat graphic.

Which tier should I choose?

The one your form or platform actually enforces, and no tighter. On this photograph a 20 KB limit returns 6.57× fewer pixels than a 100 KB limit at exactly the same quality, so choosing 20 KB "to be safe" buys nothing. Where the tier really matters is the gap between 100 KB and 200 KB: that is the step from 4.11 to 6.00 megapixels, and from the floor to 58.28% quality.

How these numbers were measured: nine encodes of this site's own compressor, one file, one target per run, each on a freshly loaded page in Chrome on Windows. Byte counts were read twice — the tool's own result panel and the produced blob through a FileReader — and agreed on all nine rows; dimensions were read twice, through createImageBitmap and through an <img> element, and agreed on all nine. Error figures come from decoding the output and comparing it with the source pixel by pixel at full size; where the output was resized the two decode paths differ by 0.004–0.015 in mean error, and the figure quoted is the createImageBitmap one. Arithmetic (bytes per pixel, ratios, the 145.6 KB crossover) is shown as division so it can be checked. No search volume, no third-party benchmark figure and no estimate appears on this page.

Already reduced it once and tempted to run it again? Running a picture through the reducer twice is measured here: same target twice returns the file untouched with every pixel identical, a deeper second pass lands within 220 bytes of one pass while giving up pixels, and each extra pass costs about a tenth of a level of mean error against the original.