Compress image size: the bytes come off the texture, not evenly

The map: 40 tiles, five budgets

The source is a 3000 × 2000 night photograph, 689,299 bytes, already JPEG. It is cut into 8 columns × 5 rows of 375 × 400 px, 40 tiles of 150,000 pixels each. Each tile's own texture is measured on the source as the mean absolute luma difference between horizontally and vertically adjacent pixels — a local gradient, in levels per pixel. Then the whole photograph goes through the compressor at one target, and each tile's mean absolute RGB error is measured against the original. The five budgets return 20,385, 61,310, 102,087, 202,286 and 511,019 bytes — the same five values this site has recorded for this photograph in every session since 30 October, which is the cheapest available proof that the encoder is deterministic.

Read down the texture column and then across: the rows that start high stay high at every budget. Tile r4c0 has the most texture of the forty (5.797 levels per pixel) and the largest error at all five targets — 4.981, 3.680, 3.106, 2.405, 1.643. Tile r0c2 has the least (0.732) and sits near the bottom of every column — 1.190, 1.206, 1.198, 0.998, 0.433. Nothing in the middle of the table crosses over. That is what a rank correlation of 0.96–0.98 looks like when you print it as forty rows instead of a coefficient.

Two ways to measure detail, and only one of them ranked this damage

Standard deviation of luma is the obvious way to describe how busy a region is. On this photograph it was also the wrong one for this purpose. It scores a smooth sky gradient high, because the tone genuinely changes a lot from the top of the tile to the bottom — but a smooth ramp is nearly free for a DCT-based encoder, since its energy sits in a couple of low-frequency coefficients that survive coarse quantization. Local gradient scores the same ramp low, because adjacent pixels differ by a level or two.

The quartile split shows the gap directly. Grouping these 40 tiles into four groups of ten by source contrast puts the highest-contrast group fourth — and that group has lower error than the third group at every one of the five budgets. Grouping by texture puts the groups in the order this picture's error column actually has.

Everything in this section is one photograph, measured once. The texture ranking is what this picture's error column looks like; whether a second picture would rank its own tiles by gradient at the same 0.96–0.98 has not been tested here, and this page does not claim it. What the measurement does support is narrower: on a night photograph with a smooth sky at the top and fine detail along the bottom, contrast ranked these 40 tiles worse than local gradient did. A sunset over water or a gravel path would be a separate experiment — a reasonable next one, not a result.

The concentration is a property of the picture, not the budget

The obvious expectation is that a tighter budget hurts everything and therefore flattens the map, and that a generous budget lets the encoder be gentle everywhere and flattens it the other way. Neither happens. The ten most-textured tiles hold 40.01% of the total error at 20 KB, 37.22% at 60 KB, 35.24% at 100 KB, 34.28% at 200 KB and 35.73% at 500 KB. The ten flattest hold 12.15%, 14.58%, 16.06%, 16.71% and 13.81%. Both series drift by a few points and neither trends to uniformity.

The ratio between the worst and best tile tells the same story with less arithmetic: 4.21× at 20 KB, 3.05× at 60 KB, 2.59× at 100 KB, 2.50× at 200 KB, 3.79× at 500 KB. The order of the tiles never changes; only the multiplier breathes. And the overall error falls hard — 2.701 to 0.997 mean levels, a 63.1% reduction for 25.07× the bytes — while the shape of where that error sits stays put.

That is worth stating plainly, because it inverts the usual advice. "Compress harder and quality drops everywhere" is not what the map shows. Compressing harder drops quality mostly in the same places it was already dropping, which means the visible result of a tight target is not uniform mush but a picture whose busy regions have gone soft while its quiet regions still look untouched. On this photograph, if a viewer complains that one part of the image looks bad after compression, the tile table is a fair reconstruction of why.

Same target, same pixel count, different content

The tile map measures the damage a shared budget does. The second experiment asks the question a person actually has: if I hand this tool a piece of a picture and ask for 30 KB, what do I get? Eight of the forty tiles were cut out losslessly as PNG — 375 × 400, 150,000 pixels each, no generation loss — and each was compressed on its own at 3, 6, 12 and 30 KB.

The 30 KB column is the cleanest single result on this page: identical target, identical pixel count, and a quality range of 10.31 points, ordered exactly by texture. The flattest crop came back at 99.53% quality with an error of 0.049 levels — visually indistinguishable from the source, and it used 30,190 of its 30,720-byte allowance to do it. The most textured crop, same 150,000 pixels, same 30 KB, landed at 89.22%.

The 3 KB column shows the floor arriving at different places. Four crops still kept every pixel at 3 KB, with quality from 79.38% down to 43.28%. From the fifth crop onward the tool ran out of quality room and started cutting pixels instead: 272 × 290, then 214 × 228 twice, then 178 × 190. Same instruction, same input size, four different outcomes, because the instruction is a byte count and the content is not the same.

Where each content type stops keeping its pixels

The tool has a hard quality floor at 40.47%. Below that it stops paying quality and starts paying pixels, which is the same boundary the 200 KB page found for the whole photograph and the JPEG size reducer page found from the channel side. What the crop sweep adds is the per-content arrival time:

• Texture 0.732 and 1.039: never reached the floor, not even at 3 KB — 79.38% and 76.09% quality with all 150,000 pixels intact.
• Texture 1.344: never reached the floor either; 68.12% quality at 3 KB, full frame.
• Texture 1.963: hit the floor exactly at 3 KB — 43.28%, still full frame.
• Texture 2.980: crossed between 3 KB and 6 KB. At 3 KB it held the floor at 272 × 290 (78,880 pixels, 52.6% of the original count); at 6 KB it was back to full frame at 56.41%.
• Texture 4.109 and 4.788: crossed at 6 KB — 360 × 384 (92.2%) and 352 × 376 (88.2%), both at the floor.
• Texture 5.797: crossed at 6 KB, down to 288 × 307 (58.9%), and at 3 KB down to 178 × 190 (22.5%). Full frame only returned at 12 KB, and then at 57.34% quality.

In allowance per pixel, a 3 KB target on 150,000 pixels is 0.0205 B/px and a 30 KB target is 0.2048 B/px — a tenfold spread in budget for the same pixel count. The whole photograph, at its five budgets, runs 0.00340 to 0.08517 B/px, a wider range because scaling a 6-megapixel frame down buys far more than scaling a small crop down.

Nothing comes back untouched

One assumption worth killing: that flat areas are free. Not one of the 40 tiles came back with every pixel identical, at any of the five budgets — 0 out of 40, including the flattest tile at 500 KB. What is true is that flat areas are mostly free at pixel level rather than tile level: at 500 KB, 28.15% of all pixels in the frame were bit-identical to the source, and inside the flattest quartile 41.32% were. At 20 KB that global share collapses to 4.02%, and inside the flattest quartile to 7.18%.

So the honest version of "flat regions survive compression" is: about two in five pixels of a flat region come back exactly, not the whole region. The rest move by a level or two, which is invisible but measurable, and it is why the error column never reaches zero anywhere on the map.

What this means when you reduce image size

The practical consequence for anyone trying to reduce image size is that the target you pick is not a quality setting — it is a budget, and in this photograph the content decides the exchange rate. A 30 KB target on a screenshot of text and a 30 KB target on a photograph of foliage would not be the same instruction, though this page measured one photograph and not that comparison. The measured spread here is 10.31 quality points between the flattest and busiest eighth of one image; what a second subject would do has not been run.

The second consequence is that the compressor has no way to protect a region you care about. A portrait with a busy background would, on the pattern this photograph shows, lose more absolute detail from the background than from the face — but that is an expectation drawn from one landscape, not something measured here: this page ran one photograph and it contains no face. If the face is what matters, the lever that does not depend on that open question is a crop — remove the busy region and the budget stops being spent on it. That is a content decision, not an encoder setting, and the encoder cannot make it for you.

How to lower image size without guessing

Because on this photograph the map was set by the picture rather than by the budget, the procedure that does not depend on guessing is: pick a target, run it, look at the result, adjust once. Guessing a quality percentage is strictly worse than guessing a byte target, since the byte target is the thing your upload form actually enforces. Two measured rules shorten the loop.

First, above 40.47% quality the tool pays quality and keeps pixels; below it, pixels start going. For a 6-megapixel frame that switch sits at 200 KB, which is the number the KB ladder and the 200 KB page both land on. Second, a file that comes back without scaling and with the tool's verdict reading "quality 100%" has essentially not been degraded — the flattest crop at 30 KB did exactly that, its internal quality setting 99.53%, so if the verdict says the target was met without scaling, there is nothing further to tune.

A photo size reducer is a budget allocator

Calling the tool a photo size reducer describes what it does to the file, not what it does to the picture. What it does to the picture is allocate a byte budget across 8 × 8 blocks, and the allocation is not negotiable from outside. The 40-tile table is that allocation made visible: 34–40% of the total damage in a quarter of the frame, and the same quarter every time, whatever the budget.

If you want a smaller file with no allocation at all — no block gets more or fewer bytes, no pixel changes — the lossless route is a different mechanism entirely, and the PNG size reducer page measures it at 18–36% smaller with every pixel identical by hash. If the file must stay JPEG, allocation is unavoidable and the only choice is how big the budget is.

An image quality reducer, read from the other side

Read the tile table backwards and it becomes a guide to spending bytes where they buy something. Going from 500 KB to 200 KB on the whole photograph costs 308,733 bytes and moves global error from 0.997 to 1.552 levels; the tiles that absorb that change are the textured ones, and the flat ones barely register it — their quartile error moves from 0.675 to 1.192 while the third quartile moves from 1.241 to 1.878. If you are choosing between two targets and the picture is mostly smooth, the cheaper target is genuinely close to the expensive one. If the picture is mostly texture, it is not.

Compress image size online, in the tab

This is an online compressor in the literal sense — it runs in a browser tab — but nothing is uploaded. The photograph is decoded, re-encoded and returned inside the page. That is also why the numbers reproduce: the five whole-frame budgets returned 20,385, 61,310, 102,087, 202,286 and 511,019 bytes, byte-identical to this site's runs on the same photograph in October and early November, and the 30 KB crop runs repeated exactly (30,190 bytes, error 0.049) when the sweep was re-executed. A compressor you can re-run is a compressor you can check, and every cell above is one run deep in a browser anyone can open.

How to compress an image with the map in mind

1. Decide whether the target is a limit or a preference. If a form enforces 100 KB, the target is fixed and the only variable is how the loss distributes. If you are choosing freely, the 40.47% floor is where quality stops buying anything and pixels start going instead.
2. Look at where the texture is before you look at the number. A mostly smooth image will hit a small target with most pixels untouched — the flattest crop here kept all 150,000 pixels at 3 KB. A textured image will not, and no target setting changes that.
3. If one region matters more, crop first. The encoder spends its budget in proportion to local detail, so removing a busy background is the only way to stop paying for it. Cropping is a content decision the tool cannot make.
4. Run once at the final target and stop. The tool is deterministic — the same input at the same target returns the same bytes — so a second pass at the same target returns the identical file, which the second-pass page measured at 0 ms of encoder time.
5. If the output must be smaller and stay JPEG, accept the pixel regime. Below the floor the tool scales, and the scaling is uniform: at 20 KB the whole 6-megapixel frame became 968 × 646, which is 625,328 pixels, or 10.4% of the original pixel count.

Questions this page gets

Does compressing an image take bytes evenly from the whole picture?

No. The ten most textured of 40 tiles absorbed 40.01% of the total pixel error at a 20 KB target and 35.73% at 500 KB; the ten flattest absorbed 12.15% and 13.81%. Twenty-five times the byte budget barely moved the concentration, because the encoder quantizes each 8 × 8 block on its own and a smooth block has little to quantize.

Why does the same target size give different quality on different pictures?

Because the target is a byte count, not a quality level. Eight 375 × 400 crops, all 150,000 pixels, all compressed to 30 KB, came back at quality settings from 89.22% to 99.53% — a 10.31-point spread set by how much texture each crop held. At 3 KB the flat crops still kept all 150,000 pixels while the most textured one was cut to 178 × 190, or 33,820 pixels.

Which measure of detail ranked where the damage landed on this photograph?

Local gradient, not contrast — on this one image. Spearman rank correlation between a tile's mean absolute luma gradient and its measured error was 0.981 at 20 KB, 0.977 at 60 KB, 0.974 at 100 KB, 0.962 at 200 KB and 0.980 at 500 KB. Contrast measured as luma standard deviation scored 0.703, 0.688, 0.681, 0.601 and 0.610 — and the highest-contrast quartile had lower error than the third quartile at every budget, because a smooth tonal ramp has high contrast and almost no texture. The ranking is a result for this photograph only; a second image has not been run.

At what file size does the compressor stop lowering quality and start shrinking the picture?

At the 40.47% quality floor, and the byte target where that floor is reached depends on content. For the whole 6-megapixel photograph the floor arrived at 100 KB and below — 2482 × 1655 at 100 KB, 968 × 646 at 20 KB. For single 150,000-pixel crops it arrived anywhere from below 3 KB (flat content, 79.38% quality still) to 12 KB (the most textured crop, 57.34% quality at full frame).

Is the image uploaded to a server when I compress it?

No. Decoding, re-encoding and the byte-target search all happen inside the tab. Every number on this page came from the same in-browser compressor you can run yourself, and no request carrying image data leaves the machine.

Can I compress an image to an exact size like 30 KB?

You can set an exact target and the tool returns a file at or under it — the 30 KB runs here returned 30,190, 30,575 and 29,922 bytes on different content. What it cannot promise is that the same target costs the same quality everywhere: the same 30 KB cost 99.53% on a flat crop and 89.22% on the most textured one.

Where the numbers come from. All figures measured on 6 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. Experiment one: one 3000 × 2000 photograph, 689,299 bytes, cut into 8 × 5 tiles of 375 × 400 px, five targets (20, 60, 100, 200, 500 KB), one run per target in a fresh tab, per-tile error measured against the source at full frame with each output upscaled back to 3000 × 2000. Experiment two: eight of those tiles re-cut losslessly as PNG and compressed separately at 3, 6, 12 and 30 KB — 32 cells. Output bytes agreed between the tool's report and a FileReader read on all 37 rows; dimensions agreed between the report and createImageBitmap on all 37; two decode paths agreed to within 0.047 levels per tile. One of the 32 crop cells returned "Compression failed in this browser" on its first attempt and produced a normal result on the immediate retry, so that message is treated as transient rather than as a content limit — it is not reported as a finding. One photograph and one photograph only: every correlation and every concentration figure on this page is a property of this single picture's texture distribution. The 0.96–0.98 rank correlation has not been re-measured on a second image, so it is reported as what happened here, not as a rule about image compression in general; a subject with a different mix of smooth and busy regions would move both the correlations and the concentration figures, and this page does not say by how much.

Read these alongside: the KB ladder puts six single-pass budgets in one page; 200 KB is where quality stops and pixels start for a 6-megapixel frame; the JPEG size reducer splits the same damage by channel; the second-pass page measures what one extra encode costs; the image quality reducer measures the marginal cost of each quality step from q=0.95 to q=0.05; WebP is what the same bytes buy in another format; and the PNG size reducer removes bytes without touching a pixel.