Image compressor to 20KB: where a 4000×6000 file stops
A 3,492,678-byte JPEG at 4000×6000 does reach 20 KB on this compressor — it came back at 452×679 and 20,341 bytes. It got there by discarding 98.72% of the pixels, and that, not the byte count, is what stops people. If you need the pixels, set the target to 1,600 KB: that was the smallest target in this test that held 4000×6000, at quality 55%.
Match your symptom to a cause
- “This target is not reachable for this image.” You have PNG selected. PNG has no quality dial, so nothing can be traded away — both test files refused at 20 KB as PNG and both produced a file as JPG. Switch the output format.
- A file under 20 KB, but the picture is a stamp. Your target sits below the pixel floor for that content. 20 KB carried 306,908 pixels of this photograph; 1,600 KB carried all 24,000,000.
- A file above 20 KB. I could not reproduce this in ten runs. Every result landed at or under the target, from 20,341 bytes to 2,324,040 bytes.
The ladder further down shows exactly which target buys which dimensions.
How to read these numbers: two images, one per type — a photograph and a page of text — so two sample points, not a distribution. They show where the wall sits for each of those two files and say nothing about the spread inside a type. And every figure below was produced after the compressor reached its 40% quality floor, at which point it stops lowering quality and takes the difference out of the pixel dimensions instead.
The file that would not go to 20 KB
4000×6000, JPEG, 3,492,678 bytes. On paper that is a routine modern camera file. Set the target to 20 KB, choose JPG, press compress, and the tool answered in 4,680 ms with 452×679, 20,341 bytes, quality 40%. Dimensions scaled to 11% of the original.
Nothing errored. That is the part worth sitting with: the tool obeyed the number I gave it and paid for it in pixels, because at that budget there was nothing else left to pay with. If you came here because your file “will not compress”, check what you actually got back — a tiny file and a failed file are different problems with different fixes.
Every target from 2,400 KB down to 20 KB
One photograph, one output format, ten targets. Nothing else changed between rows, so the only thing moving is the byte budget.
| Target | Output | Pixels | Output bytes | Quality | Pixels per KB |
|---|---|---|---|---|---|
| 2,400 KB | 4000×6000 | 24,000,000 | 2,324,040 | 76% | 10,575 |
| 1,800 KB | 4000×6000 | 24,000,000 | 1,840,934 | 61% | 13,350 |
| 1,600 KB | 4000×6000 | 24,000,000 | 1,611,977 | 55% | 15,246 |
| 1,200 KB | 3993×5989 | 23,914,077 | 1,203,239 | 40% | 20,352 |
| 800 KB | 3095×4642 | 14,366,990 | 818,290 | 40% | 17,979 |
| 400 KB | 2093×3139 | 6,569,927 | 407,089 | 40% | 16,526 |
| 200 KB | 1447×2170 | 3,139,990 | 203,474 | 40% | 15,802 |
| 100 KB | 1031×1547 | 1,594,957 | 102,207 | 40% | 15,980 |
| 50 KB | 720×1079 | 776,880 | 50,575 | 40% | 15,730 |
| 20 KB | 452×679 | 306,908 | 20,341 | 40% | 15,450 |
One image: 4000×6000 JPEG, 3,492,678 bytes, target set in KB (1 KB = 1,024 bytes), output JPG, measured 18 October 2026 in Chrome 155.0.8059.80 on Windows 11. Quality is the whole percentage the tool prints in its own verdict line. One image per type — a sample point, not a distribution. Every row at or below 1,200 KB was produced after the tool hit its 40% quality floor and cut the dimensions instead; the rows above 1,200 KB kept 4000×6000 and spent quality.
Where the line is: between 1,200 KB and 1,600 KB
Read the quality column instead of the dimensions. From 20 KB up to 1,200 KB it never moves: 40%, every row. That is the floor. The encoder has no quality left to give, so each extra kilobyte buys pixels and nothing else — which is why pixels per KB climbs from 15,450 to 20,352 across that range, peaking at 1,200 KB where quality is still at the floor and no bytes are being spent on it.
Above 1,200 KB the column jumps: 55% at 1,600 KB, 61% at 1,800 KB, 76% at 2,400 KB. The dimensions are already whole, so the extra bytes go into quality. Somewhere in that gap the tool switches from “shrink the picture” to “keep the picture, spend quality”, and 1,200 KB is the last target on the wrong side of it.
The switch is predictable, and this is the useful part for troubleshooting. Take the bytes per pixel from the 20 KB row — 20,341 bytes ÷ 306,908 pixels = 0.0663 — and apply it to the full frame: 24,000,000 × 0.0663 = 1,590,653 bytes, or 1,553.4 KB. That is the smallest target at which 4000×6000 can survive at the floor. The measurement agrees: 1,200 KB did not hold the frame, 1,600 KB did.
Same dimensions, same target, half the pixels: the text page
A second file, 4000×6000 as well, so pixel count is held constant and only the content changes. This one is a page of dense body text, 1,297,068 bytes as PNG. Its source file is smaller than the photograph's 3,492,678 bytes. It came out far worse.
| Image | Source bytes | Output at 20 KB | Pixels | Output bytes | Bytes per pixel |
|---|---|---|---|---|---|
| Photograph | 3,492,678 | 452×679 | 306,908 | 20,341 | 0.0663 |
| Text page | 1,297,068 | 334×500 | 167,000 | 20,453 | 0.1225 |
Both 4000×6000, both targeted at 20 KB, both output JPG, same browser and same session. One image per type — two sample points, not a distribution. Both outputs were produced after the 40% quality floor was reached, so neither number describes a lower-quality full-size encode; the tool does not make one.
The text page needed 0.1225 bytes per pixel against 0.0663 for the photograph — 1.85 times as much per pixel — so the same 20 KB bought it 167,000 pixels instead of 306,908. Hard edges are what JPEG spends on, and a page of 44-pixel type at this resolution is nothing but edges. If your file is a scan, a screenshot or a page of text, expect to keep 54.4% of the pixels a photograph would keep at the same target.
The arithmetic, so you can predict your own file
Both inputs are things you can get from one run. Target bytes is the number you typed, multiplied by 1,024. Bytes per pixel comes from compressing once at 20 KB and dividing the output bytes by the output pixels — 20,341 ÷ 306,908 = 0.0663 for this photograph. Put 20,480 in the top and you get 309,005 pixels, which is within 0.7% of the 306,908 the tool actually returned. The model is crude and it is honest: it is the same trade the encoder is making, written out.
Run it the other way and you get the target you need. 4000×6000 is 24,000,000 pixels, so 24,000,000 × 0.0663 = 1,590,653 bytes. Anything below that cannot hold the frame at the 40% floor, no matter how the tool searches.
The one hard refusal: PNG at 20 KB
Both files were run a second time with the output set to PNG, same 20 KB target. Both were refused, in these words:
That is the tool's own message, copied from the page. It is not a bug and not a limit on your file: PNG is lossless, so there is no quality to spend, and the only lever left is pixels — which at 20 KB runs out before the encoder reaches anything worth calling a picture. The same two files, same target, as JPG produced 452×679 and 334×500 without complaint. If you see that sentence, change the format before you change anything else.
What to change, cheapest first
- Switch the output format. Same photograph, same 20 KB target: JPG gave 452×679 (306,908 pixels), WebP gave 534×801 (427,734 pixels), PNG gave the refusal above. WebP bought 39.4% more pixels for the same budget, so it is the first thing to try if the destination accepts .webp.
- Raise the target to the number your dimensions need. Use the formula: pixels × 0.0663 for a photograph of this kind. 1200×900 is 1,080,000 pixels, so 1,080,000 × 0.0663 = 71,604 bytes, which is 69.9 KB. Set 100 KB and you clear it.
- Crop before you compress. The budget is fixed; the frame is not. Cutting the frame to the subject spends all 306,908 pixels of a 20 KB budget on the part that matters instead of on sky and road shoulder.
- Flatten busy backgrounds. A textured background costs more than the subject does. One flat colour behind the subject can move a file from the 334×500 side of the table toward the 452×679 side.
What the 20 KB output actually looks like
I opened both results at their real pixel size. The photograph at 452×679 is a usable thumbnail: the road, the ridge line and the sky all read correctly, and the double yellow line still separates from the asphalt. The rock faces on either side are mush, and the car in the distance is a grey smudge. On a phone at arm's length it holds up; at 100% it does not.
The text page at 334×500 is not readable. Not soft, not degraded — the body text is a grey field and the heading is a dark bar. If your file is a document and you need 20 KB, this is the result you will get, and no setting on the page changes it. Crop to the paragraph you need, or accept a larger target.
Questions this page gets
Why does the compressor say the target is not reachable for my PNG?
PNG has no quality dial, so the only thing the encoder can remove is pixels, and at 20 KB it runs out of them. Both test files refused as PNG and both produced a file as JPG. Change the output format.
My file is under 20 KB but the picture is unusable. What do I change?
Raise the target until the dimensions return. On this photograph: 20 KB gave 452×679, 200 KB gave 1447×2170, and 1,600 KB was the smallest tested target that held 4000×6000. If the limit is genuinely 20 KB, crop instead — 306,908 pixels is all the budget holds.
Does a smaller source file compress to 20 KB more easily?
No. The 1,297,068-byte text page is the smaller file and it got 167,000 pixels, against 306,908 for the 3,492,678-byte photograph. Detail decides this, not the starting file size.
Can I keep 4000×6000 and 20 KB at the same time?
Not with a JPEG at the 40% floor. 24,000,000 pixels against a 20,480-byte budget is 0.000853 bytes per pixel; the measured cost was 0.0663. 24,000,000 pixels against 306,908 is a factor of 78.2. To hold the frame you need 1,590,653 bytes or more.
Is 20 KB reachable at all for a 4000×6000 photograph?
Yes — 452×679 at 20,341 bytes, in 4,680 ms. The tool meets the byte target; what it will not do is meet it and keep your pixels.
All figures measured on 18 October 2026 with Chrome 155.0.8059.80 on Windows 11, using this site's compressor and two test files of 4000×6000: a JPEG photograph of 3,492,678 bytes and a rendered text page of 1,297,068 bytes. The formula above is a model fitted to one image; a photograph with different detail will sit either side of 0.0663 bytes per pixel. The other half of this question — how many pixels each content type fits into 20 KB — is measured on the 20 KB pixel budget page, and the same question at a 100 KB target, across PNG, JPG and WebP, is measured on the 100 KB PNG page.