Compress image to 100KB: what the dead frame actually costs

What 100KB bought each source, whole frame

Three sources, one target, three runs each. The kept column is the share of the source's pixels that survived. Both large sources landed on the compressor's 40% quality floor — the point at which it stops spending quality and starts cutting dimensions instead. The small source cleared the floor entirely, so 100KB bought it every pixel and a quality search that settled at 68.12%.

Measured 10 November 2026, Chrome 157.0.8103.38, Windows 11, target 100KB, format JPG, three runs per row. Output bytes were identical across all three runs of every row and matched earlier sessions of this site byte for byte where the same file and target had been run before. Times are the tool's own verdict times for each of the three runs; the independent wall clock read 10125/3800/2858, 3113/3430/3348 and 657/477/472 ms on the same rows. Time is an environment value, not a property of the file.

The 24-megapixel landscape is the case most people picture when a form says 100KB, and the answer is brutal: 1031 × 1547, 6.6% of the pixels, everything at the floor. The same picture at 6 megapixels keeps 68.5%. At 2.16 megapixels nothing is cut at all and the quality search pays instead. Which row you are in is decided almost entirely by how many pixels you hand the compressor.

The same budget with the dead band cropped away

Each source was compressed twice: whole, and again with its dead top band removed by the rule above. The subject is whatever remains — the frame minus the sky. The subject-error column is the mean absolute per-channel difference between the output, upscaled back to the subject's original pixel size, and the original pixels of that region. Both outputs are scored against the identical reference region, so the two rows of each pair are directly comparable.

Subject pixels for the whole-frame rows are the subject region as it appears inside the output (the output's scale factor times the subject's source area); for the cropped rows, the whole output is the subject. Whole-frame error is not computed for the cropped rows because those outputs contain no sky to compare against it. Subject error is identical whether the output is decoded with createImageBitmap or with an Image element — both paths agreed to four decimal places on every row.

Read the two large pairs first. The cropped landscape returned 1046 × 1209 against the whole frame's subject coverage of 1031 × 1192 — a subject-pixel gain of 2.9% (35,662 ÷ 1,228,952), with the subject error down 1.5% (6.846 → 6.740). The cropped night photo gained 2.8% subject pixels (104,584 ÷ 3,777,604) and its subject error fell 12.6% (2.304 → 2.014). Both large pairs sit at the same 40.47% floor. Then the small pair, which is the cleanest experiment of the three: identical subject pixels, identical subject error to four decimal places, identical 68.12% quality — the only difference is 1,631 bytes of output size.

So the instinct partially holds once, on one source, and fails twice. Nothing on this page suggests cropping the sky off will rescue a 100KB upload. What it changes is measured in the next section, and it is small.

What the sky actually cost

The small pair gives the sky's price directly: both outputs carry the identical subject at the identical quality, so the byte difference between them is the sky band's cost and nothing else — 102,086 − 100,455 = 1,631 bytes, or 1.6% of the budget, for the top 8.0% of the frame.

The two large pairs give an arithmetic estimate instead, because their cropped outputs carry the subject at a slightly different pixel count. Taking the cropped output's bytes-per-subject-pixel as the price of subject content: the landscape's sky cost about 102,207 − (100,947 ÷ 1,264,614 × 1,228,952) ≈ 4,107 bytes, 4.0% of the budget, for the top 22.9% of the frame. The night photo's sky cost about 102,087 − (102,078 ÷ 3,882,188 × 3,777,604) ≈ 2,759 bytes, 2.7% of the budget. These two are arithmetic on measured values, not separate measurements; the small pair's 1,631 bytes is the only direct reading.

That is the whole finding. A fifth of the landscape's frame cost a twenty-fifth of its budget. The compressor — any DCT-based JPEG encoder — spends its bytes where the detail is, and a smooth sky is nearly free. Which cuts the other way too: the cropped landscape cost 0.0798 bytes per output pixel against the whole frame's 0.0641, because removing the cheap pixels concentrates the expensive ones. The subject got 24.6% more bytes per pixel after cropping (0.0798 ÷ 0.0641) and turned that into 2.9% more pixels at the same floor quality — the encoder had already paid the sky what the sky was worth, which was almost nothing.

The average hides the damage

The whole-frame error column in the comparison table is consistently, and sometimes dramatically, lower than the subject column on the same file. On the landscape: 5.576 whole frame against 6.846 on the subject — the file average understates the damage to the content by 18.5% ((6.846 − 5.576) ÷ 6.846). On the night photo: 1.961 against 2.304, a 14.9% understatement. On the small copy, whose dead band is only 8% of the frame: 1.680 against 1.734, a 3.2% understatement.

The mechanism is the one measured tile-by-tile on the spatial-distribution page: compression damage concentrates where the texture is. A frame that is one-third smooth sky will always produce a flattering average, because the sky reconstructs nearly perfectly. The practical rule this page adds is simple: judge a 100KB result on a 100% zoom of the subject, not on the thumbnail and not on any whole-image quality score — including the ones on this site.

What actually decides a 100KB result

1. Source pixel count, first. The three sources here span 24.0 → 6.0 → 2.16 megapixels, and the outcomes span 6.6% kept → 68.5% kept → everything kept at 68.12% quality. If your file is large, no amount of frame-trimming changes which regime you are in.
2. Content density, second. At the same 40.47% floor, the landscape cost 0.0641 bytes per pixel and the night photo 0.0249 — 2.6× apart (0.0641 ÷ 0.0249). Dense content keeps fewer pixels at the same target, whatever its size.
3. The 40% floor, third. Both large sources hit it, which is why their quality columns are identical despite very different content. Below the floor the compressor cuts dimensions instead — the floor behaviour is documented across this site's other measured pages.
4. Dead frame, a distant fourth. Between 1.6% and 4.0% of the budget on the three sources measured here. Cropping it away is worth doing for the file it produces — the small cropped copy came back 1,631 bytes lighter for the identical picture — but it will not buy a better-looking subject at 100KB.

Questions this page gets

Should I crop the sky off before compressing to 100KB?

Only if you want the smaller file. Measured: the sky bands here cost 1.6–4.0% of the budget, cropping bought +2.9% / +2.8% / 0% subject pixels, and no quality step anywhere. The one unambiguous win was file size: the cropped 2.16MP copy returned the identical subject, at the identical quality, 1,631 bytes lighter.

What quality will 100KB give my photo?

If your photo is above roughly two megapixels, expect the compressor's 40% quality floor and a dimension cut — 6.6% of pixels kept at 24 MP, 68.5% at 6 MP on this page's photograph. Below about two megapixels, expect every pixel kept and a quality number in the high sixties — 68.12% here. The boundary sits where the whole frame at 40% quality first fits inside 102,400 bytes.

Why does my compressed photo look fine small but fall apart when I zoom in?

Because the smooth parts of the frame survive almost perfectly and the detailed parts take the damage, and at fit-to-screen size the smooth parts dominate what you see. The whole-frame error on this page ran up to 18.5% below the subject-region error. Zoom to 100% on the subject before you submit anything to a form.

Is my screenshot mostly empty space?

Very likely, and that is good news for a 100KB target. Measured flat-tile shares: a text screenshot was 76.3% flat, a product photograph 80.1%, a line chart 69.5%, a vector-style graphic 93.4%. The compressor spends almost nothing on those regions, which is why screenshots and charts compress to tight targets far better than photographs of the same pixel dimensions.

Does the dead frame change the pixel dimensions I get back?

Barely. The cropped landscape returned 1046 × 1209 for its 4000 × 4624 subject; the whole-frame version covered the same subject with 1031 × 1192 of its output. The cropped night photo covered its subject with 2516 × 1543 against 2482 × 1522. Both gains are under 3%, because at the quality floor the byte budget follows the detail, and the detail did not change when the sky left.

Was the test fair to cropping?

The crops were pixel-exact copies (Pillow, saved as PNG — no encoder between crop and compressor), the comparison scored both outputs against the identical subject region at its native size, and every run was repeated three times with byte-identical results. The one thing this page does not claim: that these three sources cover every kind of upload. They are three sample points on one photograph and one landscape; a noisier sky or a busier frame will move the sky's price, though probably not by much — the direct reading on the cheapest case was 1.6% of the budget.

The form-requirement side of this same target — which official photo specs actually say 100KB, why 100KB here means 102,400 bytes and what to aim at when a form means 100,000 — is measured on the compress JPG to 100KB page. Whether a PNG can reach a tight byte target at all is on the PNG at 100KB page. The same photograph at five other budgets, 20KB through 1MB, is on the six-tier ladder page; the 200KB tier's quality numbers are on the 200KB page.

Where the damage lands inside the frame, tile by tile, and why texture predicts it (Spearman ρ 0.96–0.98 on one photograph), is measured on the spatial-distribution page. How long the compressor takes at each target — including why ~100KB is the slowest one — is on the compression-time page.

This page compares a whole frame with a crop to measure what a dead band costs. A different 100KB test uses seven uncropped inputs to measure returned dimensions and aspect-ratio drift for the resize intent: resize image to 100KB. Its measurements are independent of the crop comparison above.

The separate compress image for email test measures whether GPS, capture time, camera identity and orientation survive a JPG re-encode. It uses a synthetic metadata fixture and two EXIF readers; this page's crop and subject-error experiment is not part of that test.

A different controlled 100KB experiment applies synthetic RGB perturbations to one photograph before compression: compress photo to 100KB with synthetic noise. It reports PNG input bytes, JPG output error and timings; it does not claim to model camera sensor grain or reuse this page's dead-frame comparison.