Compress PNG to 100KB: what a PNG can actually reach

Five PNGs, one 100 KB target, three formats

Same target, same session, same browser. The only things changing between rows are the picture and the output format.

Measured 18 October 2026, Chrome 155.0.8059.80 on Windows 11, target set to 100 KB (102,400 bytes). “Untouched” means the file was already under the target and already PNG, so the compressor passed it through without re-encoding — 0 ms in its verdict line. One image per type; five sample points, not a distribution.

Read the PNG column top to bottom and the range is enormous: one file refused outright, two kept 0.47% and 2.4% of their pixels, two kept every pixel. Now read across the gradient row — PNG dropped to 374 × 249 while JPG and WebP both kept the entire 2400 × 1600 frame. Same file, same 100 KB, a factor of 41 in pixels. That is the whole question this page answers, and it is not a matter of settings.

Why: PNG pays 1.9 bytes for a pixel that a JPEG pays 0.06 for

Divide output bytes by output pixels and the behaviour stops looking random. Each format has a price per pixel, and PNG's price depends entirely on whether neighbouring pixels are similar.

All values computed from the table above, except the one marked †. That figure is the browser's own PNG encoder, measured across the eight-target ladder further down (1.826–1.932 bytes per pixel, targets from 150 KB to 3,200 KB, because PNG at 100 KB returned nothing to divide). It is a re-encode at reduced dimensions, so it is not the same measurement as the two source-file figures at the bottom of the table. Do not divide 1.90 by 0.00479 and call it a range.

For a like-for-like comparison, use the two files as they exist, both at full size. Same format, same lossless rule, same 100 KB question — the only difference is the content.

Four raw numbers, two divisions: the photograph's file size and pixel count, the flat graphic's file size and pixel count. PNG is lossless for both, so the only thing that changed is how much the pixels resemble their neighbours — and the photograph costs 157 times as much per pixel. Anybody can redo that on the two files with a calculator; the numbers are in the first table above.

PNG stores every pixel exactly. Its compressor works by predicting each pixel from the ones already coded and then deflating the leftovers. In flat art the leftovers are almost all zero, so a 4000 × 4000 graphic fits in 84,394 bytes. In a photograph the leftovers are close to noise, and noise does not deflate — 0.83 bytes per pixel is what is left in the file you already have, and 1.90 when this compressor re-encodes it at reduced dimensions. JPEG, by contrast, throws away high-frequency detail on purpose and lands at 0.064.

Those two prices — 0.83 for the file, 1.90 for the browser's encoder — are worth keeping apart. A browser canvas is not an optimiser; it does not try filter combinations or palette tricks. So re-encoding a photograph at unchanged dimensions costs about 2.3 times as many bytes per pixel as the file it came from, and “compress this PNG” can genuinely hand back something larger than the one you started with. For a photograph, the only direction PNG can go is down in pixels.

The photograph: where 100 KB sits below the floor

The 19,887,619-byte photo refused 100 KB. To find out how far below the floor that is, I ran the same file as PNG at eight targets.

One file: 4000×6000 photograph, 19,887,619 bytes as PNG, output PNG, same browser and session as every other table here. Eight targets, one image — sample points, not a distribution.

The bytes-per-pixel column barely moves, 1.83 to 1.93, which is what makes the encoder predictable. Take 1.90 — the price of this tool's PNG encoder at reduced dimensions, which is exactly the price you need when predicting what the tool will hand back — and the arithmetic is trivial:

102,400 ÷ 1.90 = 53,895 pixels — about 190 × 284 at this 2:3 aspect ratio, or 232 × 232 if the frame were square. That is what a 100 KB PNG of this photograph would have to be. The compressor's resolution search never goes below 5% of each dimension — 200 × 300 here — and 60,000 pixels at 1.90 bytes already costs about 114,000 bytes, over the whole 100 KB budget. The smallest encode it actually returned was 230 × 345 at 151,424 bytes, from a 150 KB target. So the floor for this file sits somewhere between 120 KB and 150 KB, and 100 KB is under it. The refusal is arithmetic, not a bug, and no setting on the page moves it.

Note what the 3,200 KB row implies. Extrapolating 1.90 to the full frame — 24,000,000 × 1.90 = 45,600,000 bytes, about 43.5 MB — is arithmetic on a measured constant, not a run: the largest frame I actually encoded was 1091 × 1636. But the direction is not in doubt, because the price per pixel barely moves across 150 KB–3,200 KB. There is no target at which this photograph stays 4000 × 6000 as a PNG and is smaller than the 19.9 MB you already have. PNG is the wrong container for this picture, at every size.

The text page: 100 KB buys 6% of the pixels

A 4000 × 6000 page of 44-pixel body text, 1,297,068 bytes as PNG. It is the friendliest case PNG has among the three “real content” types here — hard black glyphs on white deflate well — and it still collapses.

One file: 4000×6000 text page, 1,297,068 bytes as PNG, output PNG, same session. The 1,600 KB row was passed through untouched — the original file already fits 1,600 KB, so the tool returned it byte for byte rather than re-encoding. The real cost of holding this page at full size is therefore the original 1,297,068 bytes, or 1,266.7 KB.

Holding 4000 × 6000 costs 1.24 MB — 12.7 times the 100 KB budget. And the 100 KB version is 274 × 411, which is a page of text at 3-pixel type. There is no reading it. If the destination wants 100 KB and the file is a document, the output is a thumbnail of a document, and the only useful move is to crop to the paragraph you need before compressing.

A smaller document behaves the same way. A 1200 × 1600 PNG of 233,773 bytes — a normal-sized page, not a giant scan — came back at 318 × 424 and 100,591 bytes at the 100 KB target: 134,832 pixels out of 1,920,000, or 7.0%. At 150 KB it reached 445 × 594, at 200 KB 521 × 695. Smaller input does not mean PNG suddenly becomes a compressor; it means fewer pixels are thrown away.

Where PNG wins, and where converting to JPG makes it worse

The flat-art row is the one people get wrong. 4000 × 4000, 84,394 bytes as PNG — that is 0.00527 bytes per pixel, and it is already inside 100 KB. The tool's verdict says it plainly: “the file was already inside your limit and already PNG, so it was passed through untouched.” Zero pixels lost, zero colour lost.

Converting that same file to JPG to “make it smaller” produced 3139 × 3139 at 101,300 bytes. That is 38% of the pixels gone and the file 20% larger. At 100% the white bars and the wordmark show grey halos where the JPEG ringing sits against the blue. For artwork with few colours and hard edges, PNG is not the compromise — it is the best available option, and the browser's PNG encoder is good at exactly this content.

The cutout is the second case. 3600 × 3600 RGBA, 62,081 bytes, passed through untouched with its transparency intact. As JPG it kept all 12,960,000 pixels at 102,064 bytes — and lost the alpha channel, because JPEG has none: the encoder fills white behind the image before drawing it. The transparent area around the subject became a white rectangle. WebP is the only lossy option that keeps the alpha, and here it also beat the original: 49,862 bytes at 3600 × 3600, quality 100%.

What to do with your own PNG, in order

1. Check the file size first. If it is already under 100 KB, nothing needs to happen. A flat graphic at 84,394 bytes and a cutout at 62,081 bytes were both already there.
2. Decide what is in the picture. Flat colour, logos, UI, line art → PNG is the right format, keep it. Photograph, scan, gradient, screenshot of a photo → PNG will not reach 100 KB, and the question becomes which format to switch to.
3. Need transparency? Go to WebP, not JPG. WebP keeps the alpha channel and produced 49,862 bytes where PNG produced 62,081 and JPG produced 102,064 with the background painted white.
4. Photograph at 100 KB? WebP first, JPG second. On the 4000 × 6000 photo WebP held 2,193,126 pixels against JPG's 1,594,957 — 37.5% more picture for the same budget, at quality 41% against 40%.
5. Destination insists on .png? Then resize before you compress. 100 KB of PNG holds about 53,895 pixels of a photograph — 190 × 284 at this shape. Resize to that yourself so you choose the crop and the resampling, instead of letting the compressor hand you 230 × 345 of whatever it decided to keep.
6. Keep the original. Every one of these conversions is one-way. The 19.9 MB PNG is the only copy that has all 24,000,000 pixels.

How to tell whether the 100 KB file is still usable

Open the output at 100% and look at the busiest 200 × 200 pixels, not the whole frame. On the photograph at 1031 × 1547 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 both sides are mush and the distant car is a grey smudge. At phone size it holds. At 100% it does not.

The gradient at 374 × 249 is the opposite failure: no detail to lose, so what you see is banding — the smooth blue-to-white ramp turns into visible steps, and the steps get worse the moment anything upscales the file. The JPG at 2400 × 1600 and 90,609 bytes kept the whole frame and showed none. Same 100 KB, and the format choice was worth 41 times the pixels.

Questions this page gets

Can a PNG be compressed to 100 KB without losing quality?

Not while it stays a PNG. There is no quality value to lower, so the only lever is the pixel count: 274 × 411 from a 4000 × 6000 text page, 318 × 424 from a 1200 × 1600 document. Both files are still pixel-perfect; they just carry 0.47% and 7.0% of the original pixels.

Why will my PNG not compress to 100 KB at all?

100 KB is under the smallest PNG the encoder can produce for that content. This tool's PNG encoder spends 1.90 bytes per pixel at reduced dimensions, so 102,400 bytes buys 53,895 pixels — about 190 × 284 at this shape — and the resolution search stops at 5% of each side, which already costs about 114,000 bytes. 110 KB and 120 KB were refused; 150 KB returned 230 × 345 at 151,424 bytes.

Does converting a PNG to JPG remove the transparent background?

Yes. JPEG has no alpha channel and this compressor fills white behind the image first. The 3600 × 3600 cutout kept all 12,960,000 pixels and its transparency as PNG; as JPG it came back at the same dimensions and 102,064 bytes with the background painted white. WebP kept the alpha and produced 49,862 bytes.

Is 100 KB enough for a logo or a screenshot?

Usually yes. A 4000 × 4000 flat graphic of 84,394 bytes was already under the target and passed through untouched at full resolution. Converting it to JPG made it worse — 3139 × 3139 at 101,300 bytes, with halos around the hard edges.

PNG or WebP at 100 KB — which keeps more of the picture?

WebP for photographs and gradients: 2,193,126 pixels against JPG's 1,594,957 on the photo, and the entire 2400 × 1600 frame on the gradient where PNG fell to 374 × 249. For flat art the order flips — PNG held 4000 × 4000 at 84,394 bytes, WebP 4000 × 4000 at 89,376.

All figures measured on 18 October 2026 with Chrome 155.0.8059.80 on Windows 11, using this site's compressor and five test files: a 4000×6000 photograph stored as PNG (19,887,619 bytes), a 4000×6000 text page (1,297,068 bytes), a 4000×4000 flat graphic (84,394 bytes), a 3600×3600 transparent cutout (62,081 bytes) and a 2400×1600 gradient (2,537,877 bytes), plus a 1200×1600 document (233,773 bytes). One image per type — these are sample points, not a distribution, and a different photograph will sit either side of both 0.83 bytes per pixel (the file) and 1.90 (this tool's encoder). How many pixels each content type fits into 20 KB instead of 100 KB is measured on the 20 KB pixel budget page, and what to do when a target is refused at all is on the 20 KB troubleshooting page.