Compressing a JPEG to 20KB: 532 pixels wide, and the two reasons it fails
A JPEG is not a bag of bytes you can squeeze. Every compression rebuilds it from pixels, in 8 × 8 blocks, and the tool will not take quality below 40%. Measured on this site's compressor: a detailed 1600 × 1600 photograph came back from a 20KB target at 531 × 531 pixels in 20,192 bytes, quality 40.5%. In 102 runs across eleven image types, 89 settled at 40.5% and three images never spent the 20KB at all. Those two facts are the whole story of this target.
The short answer, measured on 23 October 2026
- A detailed photograph gets about 532 pixels on its longest side. 1600 × 1600 in, 531 × 531 out, 20,192 bytes, quality 40.5%. Demanding 90% quality instead gives 305 px — the pixels are what paid.
- Most outputs sit on the floor, not on the target. 89 of 102 runs reported 40.5% quality. When you see that number in the verdict line, the tool has stopped trading quality and started throwing pixels away.
- Three of eleven test images could not use 20KB. A white-filled pad, a black one and a solid colour all came back whole at 17,630–17,637 bytes: the compressor found nothing to spend the remaining 3,000 bytes on.
- One picture with the right structure refuses to break. A chart repeated every 8 pixels kept all 1,200 × 1,200 pixels at every quality from 40% to 95% and never exceeded 18,880 bytes, because JPEG's own block grid matches the pattern.
Every byte count, dimension and quality figure below is what this site's compressor printed in its own verdict line for these files on 23 October 2026, or an encoder measurement made against the same decoded pixels. Test conditions and the full file list are at the foot of the page.
How these numbers were produced: a local copy of this site's compressor, driven in Chrome 155.0.8059.85 on Windows 11 on 23 October 2026, one file per page load so no state carried between runs. Eleven generated images of known structure — a real photograph, the same photograph letterboxed onto four different pad colours so every variant has exactly 2,560,000 pixels, a colour-bar sheet, a global-noise series, a flat graphic, a 32-cycle line pattern and a detail-matched crop — pushed through the tool at the targets listed with each table. Where a table says encoder rather than tool, the numbers come from re-encoding the same decoded pixels at a stated canvas width and quality, which is the exact operation the tool's search performs. What this page does not repeat: how many pixels 20KB holds for each kind of picture (that is the content-type table), how a 24-megapixel file walks a ladder of targets (the troubleshooting ladder), or what the format change itself costs (the conversion page).
The number you need is 532 pixels wide, and here is where it comes from
One photograph, 1600 × 1600, running through the tool at eight targets from 40KB down to 6KB. The dimensions fall by roughly the square root of the target, which is what you would expect if the tool were keeping quality constant — and it is, to within half a point.
| Target | Output size | Output bytes | Quality | Pixels kept |
|---|---|---|---|---|
| 40 KB | 798 × 798 | 40,355 | 40.5% | 24.9% |
| 30 KB | 668 × 668 | 30,201 | 40.5% | 17.4% |
| 20 KB | 531 × 531 | 20,192 | 40.5% | 11.0% |
| 15 KB | 451 × 451 | 15,317 | 40.5% | 7.9% |
| 12 KB | 392 × 392 | 12,197 | 41.4% | 6.0% |
| 10 KB | 353 × 353 | 10,199 | 40.5% | 4.9% |
| 8 KB | 306 × 306 | 8,178 | 40.5% | 3.7% |
| 6 KB | 258 × 258 | 6,137 | 41.4% | 2.6% |
Source: 1600 × 1600 JPEG, 571,271 bytes, a crop of a 24-megapixel photo placed on a white 1600 × 1600 canvas. Output format JPG. "Pixels kept" is output pixels ÷ 2,560,000 of the padded canvas.
Read the quality column. Every target from 40KB down to 6KB, a factor of nearly seven, landed within one point of 40.5%. The tool has a floor at 40% and these targets all sit below what that floor can deliver, so quality never moved and the pixel count did all the work. That is the first reason a 20KB JPEG disappoints: the budget is not being spent on quality compression, it is being spent on deletion.
The second thing to notice is what "531 × 531" means in the hand. A phone shot is 12 megapixels; this is 0.28 megapixels, about 2% of it. At 531 pixels wide the picture is the size of a thumbnail in a support article, on the edge of usable as a chat avatar, and useless for anything that will be looked at closely. If the number in the verdict line is the problem, the fix is the target, not the format — a 100KB budget on the same kind of file is measured here.
The quality floor is why 89 of 102 runs reported the same number
Across every image and target on this page — eleven files, 102 runs — the tool returned 40.5% quality 89 times, and 49 times it returned exactly 40.5% with no variation. The other outputs sat at 41.4%, 42.3%, 43.3%, 48.4%, 57.3% and higher, always on images whose structure made a different trade possible.
| What the verdict line says | What the tool decided | What you can do about it |
|---|---|---|
| "dimensions scaled to 33%, quality 40%" | Pixels were sacrificed; quality never left the floor. | Raise the target, or accept a small picture. |
| "original dimensions kept, quality 68%" | The whole budget went into quality; every pixel survived. | Nothing. This is the good outcome. |
| Output far below the target (17 KB against 20 KB) | The encoder ran out of things to spend bytes on. | Nothing. A smaller file is not a failure. |
Wording in the left column is the pattern of this tool's own verdict line, not a quotation of any page. The decisions in the middle column are read from the numbers, not from the source.
The useful habit: after compressing, read the two numbers in that sentence — the percentage and the word "scaled". If it says a percentage at 40% and a scale far below 100%, you are looking at a picture that has been shrunk, not compressed, and no amount of re-running will improve it.
Not every 20KB JPEG is a thumbnail — flat artwork keeps all its pixels
The same tool, the same 20KB target, five different kinds of picture. The spread is not a factor of two; it is the difference between "kept everything" and "kept a third".
| Picture | Source | Output at 20KB | Bytes | Quality |
|---|---|---|---|---|
| Flat graphic with a few large areas | 1200 × 1200 | 1200 × 1200 | 17,633 | 99.5% |
| Two-tone line pattern, 4 cycles | 1200 × 1200 | 1200 × 1200 | 12,425 | 99.1% |
| Line pattern, 16 cycles | 1200 × 1200 | 973 × 973 | 20,320 | 57.3% |
| Line pattern, 32 cycles | 1200 × 1200 | 570 × 570 | 20,447 | 40.5% |
| Line pattern, 128 cycles | 1200 × 1200 | 432 × 432 | 20,360 | 42.3% |
| White-noise field, σ 8 levels | 1200 × 1200 | 911 × 911 | 20,027 | 40.5% |
| White-noise field, σ 32 levels | 1200 × 1200 | 496 × 496 | 20,442 | 41.4% |
All six rows: 20 KB target, JPG output, source dimensions 1200 × 1200. The flat graphic is a synthetic built from four large blocks plus a colour bar; the cycles are alternating vertical bars across the full height; the noise rows are per-pixel Gaussian deviation around mid-grey, one fixed seed.
The bottom row is the useful one. A noise field with a standard deviation of 32 levels — about what the shadows of a badly lit phone photo look like at close range — lost 83% of its pixels at a budget that a flat poster spent entirely on quality. 20KB holds 1.44 megapixels of clean artwork or 0.25 megapixels of grain, and nothing in between is a rule.
This is also why the answer to "what does a 20KB JPEG look like" depends entirely on where the picture came from. A screenshot of text on a white background sits near the flat row: it keeps its dimensions and stays readable. A photo of foliage sits near the noise row: it turns to mush. If you are compressing a batch, treating screenshots separately from photographs — the folder run is measured here — is not over-engineering.
Two pictures where the tool did not use the budget at all
Compressing "to 20KB" does not mean "make it 20KB". It means "make sure it is no larger than 20KB", and for some images the honest answer is that the picture is already as small as the encoder can make it. Three of my eleven test files did this: the photograph on white, the same photograph on black, and the same photograph on mid-grey, all padded to identical 2,560,000 pixels.
| Source file | Source bytes | Output at 20KB | Quality | Unused |
|---|---|---|---|---|
| 1600 × 1600, white pad | 571,271 | 17,630 | 99.5% | 2,850 B |
| 1600 × 1600, black pad | 569,769 | 17,630 | 99.5% | 2,850 B |
| 1600 × 1600, mid-grey pad | 569,540 | 17,630 | 99.5% | 2,850 B |
| 1200 × 1200, solid colour | 40,002–40,007 | 17,630 | 99.5% | 2,850 B |
The three pads are the same photograph, the same crop, the same 1,000,000 picture pixels, on canvases of identical area. Quality is the tool's reported maximum, 0.9953125. "Unused" is 20,480 minus the output size.
Two separate findings are hiding in that table. First, the pad colour did not matter: white, black and grey came back within 16 bytes of each other, so the colour of the background you paste a picture onto is not a lever here. Second, an image that already encodes to under 20KB at maximum quality simply stops — and since a 1200 × 1200 solid colour costs 17,630 bytes in this browser's encoder, 2KB of every 20KB budget is unreachable for flat artwork.
That 17,630 number is worth remembering, because it is effectively a floor for a 1200 × 1200 JPEG in this browser. It is not image data — a solid colour has none. It is the encoder's own overhead: headers, quantisation tables, Huffman tables, and the minimum cost of coding one block. In the next section you can watch that floor appear from the other direction.
Why a JPEG cannot simply be squeezed: it is rebuilt in 8-pixel blocks
Every time this tool compresses a JPEG it decodes the file to pixels, redraws them on a canvas at a chosen size, and runs the browser's JPEG encoder over the result. The encoder works in 8 × 8 pixel blocks, left to right, top to bottom, and it spends almost nothing on a block whose 64 pixels are similar. That single fact explains the two impossible things you just saw: flat artwork that will not use the budget, and a chart that refuses to shrink.
To measure it directly I drew a two-tone checkerboard whose square size doubles as the test: a pattern repeating every 8 pixels lines up exactly with the encoder's blocks, so every block becomes a single flat tile. Every other period straddles block borders. Same 1024 × 1024 canvas, same two colours, encoded at quality 75 and again at 60:
| Pattern period | At quality 75 | At quality 60 | Why |
|---|---|---|---|
| 1 px | 148,221 B | 107,260 B | Single-pixel alternation: worst case in any block |
| 2 px | 137,981 B | 117,501 B | Still four edges per block |
| 3 px | 344,239 B | 271,842 B | Period shares no factor with 8: every block differs |
| 4 px | 137,981 B | 101,116 B | Two tiles per block |
| 6 px | 319,435 B | 267,350 B | Straddles blocks the same way as 3 |
| 8 px | 15,093 B | 14,069 B | One flat tile per block: 24.7× cheaper than 6 px |
| 10 px | 185,526 B | 161,081 B | Falls out of step with the grid |
| 16 px | 10,933 B | 10,429 B | Two clean tiles per block |
| 32 px | 8,917 B | 8,665 B | Clean grid, bigger tiles |
| 64 px | 7,909 B | 7,783 B | Clean grid |
| 128 px | 7,405 B | 7,342 B | Clean grid, approaching the header floor |
| 240 px | 7,161 B | 7,129 B | Five tiles across; cost is all header now |
1024 × 1024 canvas, checkerboard alternating between grey levels 100 and 228, encoded at quality 75 and again at 60. Encoder measurements, not tool runs. In both columns every period that is a multiple of 8 comes in under every period that is not: the fourteen multiples of 8 all fall between 7,161 and 15,093 bytes, the ten others between 20,824 and 344,239.
The lesson generalises badly, in the useful direction. Nobody's photo is an 8-pixel grid, which is why photographs lose pixels. But plenty of the things people compress to 20KB are near-grid content — a chart exported at device pixel ratio 2, a spreadsheet screenshot, a UI mock-up, a captioned diagram — and those can keep their pixels at 20KB where a photograph cannot. Try one before you accept a resized photograph as the answer.
Two questions the byte meter answers exactly
The tool's search is two steps: find the largest canvas that fits at 40% quality, then raise quality at that canvas until it no longer fits. Both steps encode the same pixels repeatedly. So I drove the encoder directly on the same decoded image, at chosen canvas widths and qualities, and read the byte count for each pair. That gives answers the tool cannot give you on its own.
First: what if you demand high quality and let the pixels go? Here is the widest canvas that still fits 20,480 bytes, for the same four padded photographs, at eight quality levels.
| Quality | White pad | Black pad | Grey pad | Red pad |
|---|---|---|---|---|
| 40% | 532 px | 537 px | 537 px | 538 px |
| 50% | 493 px | 496 px | 496 px | 496 px |
| 60% | 456 px | 463 px | 463 px | 464 px |
| 70% | 415 px | 433 px | 433 px | 433 px |
| 80% | 372 px | 374 px | 374 px | 374 px |
| 90% | 305 px | 305 px | 305 px | 305 px |
| 95% | 249 px | 256 px | 256 px | 256 px |
Binary search on canvas width, encoding the 1600 × 1600 source at each step, target 20,480 bytes. Each cell is the largest width whose encode still fits, checked byte by byte at that width and at the next integer up. Encoder measurements.
The interesting column is the first one: white padding is consistently more expensive than black or grey at the same width, and at 40% quality the gap is five pixels — 532 against 537. A white background is not free: it puts a hard edge at the picture boundary, and JPEG has to spend bytes describing it. Padding black instead of white buys about a percent of the width back, which is real but not worth redesigning anything for. What matters more is the shape of the column: going from 40% to 90% quality costs 43% of the pixels, and going from 40% to 95% costs more than half.
Much less than you might fear. Take a decoded image, encode it at a given quality, then change a single pixel to white and encode again at the same quality. Here is the difference in bytes, on three images, at three qualities:
| Image | At 60% | At 75% | At 90% |
|---|---|---|---|
| 1600 × 1600 photograph, white pad | 0 B | 0 B | 0 B |
| 1000 × 1000 photograph crop | −2 B | +9 B | +45 B |
| 1200 × 1200 colour-bar chart | +51 B | +64 B | +50 B |
One pixel at (100, 100) set to white, everything else identical, same canvas, same quality. Encoder measurements. The negative value is a real result, not a rounding artefact: changing a pixel altered how a block was coded and the file came out two bytes smaller.
So a stray white pixel is worth 50 to 64 bytes in a chart and nothing at all in a detailed photo — which is roughly one ten-thousandth of a 20KB budget. Do not spend time hunting for dust specks. And a plain re-save, drawing the decoded image back through a canvas at the same size, reproduced the original byte count exactly in all nine tests across the same three files: zero bytes lost to a second generation, because the tool always re-encodes from decoded pixels rather than trimming the file it was given.
The one re-save that does cost you. A JPEG that has already been through one lossy pass at a low quality has less detail left to give, so a second pass at the same size spends its budget on artefacts from the first. The measurement above used images straight from a lossless or near-lossless source. If your file has already been saved at 50% quality once, the honest move is to start from the original rather than to re-compress the copy.
When not to use this tool at all for a 20KB JPEG
Three cases where 20KB is the wrong target and the right answer is a different number. All three are measured elsewhere on this site, so I will only point at them.
If a form says 100KB or more, the pixel budget roughly triples and a portrait can survive intact. The 100KB page measured nine outputs that all landed between 100,825 and 102,384 bytes and explains why a form that means 100,000 bytes will reject all of them.
If you need the file to be a JPG but the source is a PNG, the conversion step itself matters more than the target: transparency is filled white, EXIF is dropped, and a file that was already under the limit can come back 7.4× larger. That is measured on the conversion page.
If the picture is already 17,630 bytes at 1200 × 1200 and perfect, nothing here applies and you should stop. Run it, check the verdict line says quality is at its maximum and the dimensions were kept, and accept the file. A 17KB output is a better result than a 20KB one, and no tool will tell you that as clearly as its own byte count does.
Doing it, in four steps
1. Open the tool and set the output format to JPG.
2. Set the target to 20 KB — 20,480 bytes here. If the receiving
form says 20,000 bytes, use 19 KB. 3. Drop the JPEG in and press Compress, then
read the verdict line for two numbers: the percentage and whether the dimensions were scaled.
If it says 40% and a scale well under 100%, the target is too small for this picture and re-running
will not help. 4. Download and check the file opens; the download is named
-20kb.jpg and the verdict line quotes the exact byte count, so compare it with what
the form accepts before uploading.
If the result is too small to use, the lever is the target — 50KB, 100KB, 200KB or 1MB all have their own measured pages on this site — or the content: downsampling the picture in an image editor first, then compressing, gives you control over where the detail goes instead of letting the encoder decide.
Questions
Why does compressing a JPEG to 20KB make it so small?
Because it is rebuilt in 8 × 8 blocks with a 40% quality floor, and the pixel count is what gives way. A 1600 × 1600 photograph came back at 531 × 531, 20,192 bytes, 40.5% quality. Demanding 90% instead gives 305 × 305 at the same byte count.
Can a 20KB JPEG still look acceptable?
For the right content, yes. Flat artwork kept every one of 1,200 × 1,200 pixels at 99.5% quality and only cost 17,633 bytes. A 1,200-wide line pattern at 16 cycles kept 973 pixels at 57.3%. Detailed photographs lost between 83% and 89% of their pixels at the same target.
Why did my JPEG stop shrinking and start losing resolution?
The tool will not go below 40% quality. Once the target is smaller than what 40% can deliver at full size, the only remaining lever is dimensions. In 102 measured runs, 89 came back at 40.5% quality.
Does re-saving a JPEG to 20KB lose more than compressing it once?
Not in this tool: a re-save from decoded pixels reproduced the same byte count exactly in all nine tests. Changing a single pixel added 45 to 64 bytes on a 1200-wide chart and nothing on a detailed photograph.
Is 20KB 20,000 or 20,480 bytes?
20,480 in this tool. Of the outputs measured here that fit, the smallest was 19,570 bytes and the largest 20,462. Aim at 19 KB if the form means 20,000.
All figures measured on 23 October 2026 with Chrome 155.0.8059.85 on Windows 11, driving a local copy of this site's compressor, one file per page load. Test set: eleven generated images — a 1000 × 1000 crop of a 24-megapixel photograph, the same crop padded on white, black, mid-grey and red to exactly 2,560,000 pixels each; fourteen 1200 × 1200 solid colours; an 8 × 8 colour-bar sheet; line patterns at 0, 2, 4, 8, 16, 32, 64 and 128 cycles; Gaussian noise fields at σ 0 to 32 levels; and a 1024 × 1024 checkerboard series for the block-grid test. Tool runs are quoted as the tool printed them; encoder measurements come from re-encoding the same decoded pixels at a stated width and quality. These are sample images with chosen structure, not a survey of real photographs: a portrait against a plain wall behaves like the flat rows, a foliage shot behaves like the noise rows. Byte counts were reproducible across runs; the millisecond timings were not, which is why no timings are quoted. HEIC and progressive JPEG inputs were not tested. For the pixel budget of each content type rather than the mechanics of this target, see the 20KB content-type table; for a single large file failing outright, the ten-target ladder; for the folder case, the batch run.
Wider budgets, measured the same way: 50KB and 200KB for a photograph, a text page and flat artwork, and 1MB, where twelve of fifteen runs kept every pixel.