Compress PNG
Drop a PNG and get two smaller copies written in this tab: one with every pixel untouched, and one with a reduced palette. The first card re-packs the same picture; the second drops colours and tells you exactly how many pixels changed. PNG in, PNG out — transparency stays, nothing is uploaded.
Drop a PNG here
or choose a file · or paste a screenshot with Ctrl + V · one file, up to 40 MP
The lossless card is always computed. This slider only moves the second card: fewer colours, smaller file, more pixels changed.
PNG in, PNG out · transparency kept · up to 40 megapixels · no upload · no account · no watermark
Compress PNG: The Two Savings Inside One File
A PNG can get smaller in two unrelated ways, and they are not interchangeable. The first is a better packing of the same picture: the pixels never change, only the bytes that describe them. The second is fewer colours: the picture itself changes, and the file can drop by half or more. This page computes both copies at once and prints the bill for each, because the right choice depends on whether you are holding a photograph or a drawing.
On a 1,440 × 900 browser screenshot the split is easy to see. The file arrived at 106,825 bytes. Re-packing returned 80,314 bytes with no pixel touched. A 128-colour palette returned 45,343 bytes and moved 53,328 pixels. Same picture on screen, three very different sets of consequences.
Two kinds of slack, and only one of them is free
Every PNG stores pixels as filtered rows and then squeezes those rows with deflate. Both steps leave room for a second attempt: a different filter per row, a different arrangement of the same bytes for the compressor. None of it touches a pixel.
The other slack is the colour table. A 24-bit PNG can name 16.7 million colours. A logo or a screenshot rarely uses more than a few thousand, and an indexed PNG stores one palette plus one small number per pixel. That is where the large savings live, and it is also the only one of the two that changes what you see.
| File (what it is) | Bytes in | Lossless copy | Palette copy |
|---|---|---|---|
| Screenshot, 1,440 × 900, 5,851 colours | 106,825 | 80,314 (−25%) | 45,343 (−58%) |
| Photo, 1,600 × 1,200, 30,156 colours | 205,222 | 212,409 (+3.5%) | 93,680 (−54%) |
| Logo, 800 × 800, alpha, 1,196 colours | 46,774 | 39,876 (−15%) | 16,939 (−64%) |
| Diagram, 1,200 × 600, 5 colours | 3,617 | 2,240 (−38%) | 2,240 (−38%) |
| Gradient, 1,200 × 600, 432 colours | 3,785 | 3,787 (+0.05%) | 4,571 (+21%) |
| 16-bit grey ramp, 900 × 600 | 2,432 | 4,508 (+85%) | 3,329 (+37%) |
Two rows in that table exist to keep the page honest. The photograph's lossless copy came out 7,187 bytes larger than the original, and the gradient's came out 2 bytes larger. Re-packing is not a discount you can count on.
What a lossless re-pack actually returns
The tool builds two packings of the same rows: one where every row picks its own filter (none, sub, up, average or Paeth), and one where no row is filtered at all. Both go through the same deflate step and the smaller file wins. On the screenshot the unfiltered copy won by 27,662 bytes; on the photograph the filtered copy won, and the result was still larger than the file that came in.
That is the whole story of lossless PNG compression in one comparison. A screenshot straight out of a browser is full of long identical runs, and a filter can break those runs into shorter residuals. A file written by an image library has usually been packed once already, so a second attempt finds almost nothing.
There is no setting on this page that promises a smaller file. The lossless card tells you what the attempt returned. When the result is bigger, the download button offers the original instead, which is the honest answer.
The palette copy: 8 bits per pixel, then 4, then 2, then 1
An indexed PNG stores a palette (the PLTE chunk, three bytes per colour) and then packs pixel indices at the narrowest bit depth that fits. Up to 2 colours need 1 bit per pixel, up to 4 need 2 bits, up to 16 need 4 bits, and anything larger uses 8. The bit depth is chosen from the palette the picture actually needs, not from the slider value.
That is why the five-colour diagram shrank from 3,617 to 2,240 bytes with zero pixels changed: it fits in a 4-bit palette, and the same image stored as 24-bit RGB had been paying three bytes per pixel for five colours.
The slider decides how many colours the palette may hold, and the file follows it without much drama on flat artwork:
| Palette | Screenshot, 1,440 × 900 | Photograph, 1,600 × 1,200 |
|---|---|---|
| 256 colours | 48,438 B | 102,037 B |
| 128 colours | 45,343 B | 93,680 B |
| 64 colours | 42,480 B | not measured |
| 32 colours | not measured | 68,588 B |
On the screenshot, cutting the palette from 256 colours to 64 saved 5,958 bytes. That is about 12% of the file. Most of that screenshot is text and panel edges, which are already flat; the colours were never the expensive part. On the photograph the same move was worth far more, because a photograph spends its bytes on subtle colour variation.
Where the pixels move, and by how much
A palette copy is lossy the moment the picture holds more colours than the palette allows. The card reports how many pixels moved, the largest single-channel change, and the peak signal-to-noise ratio, all measured against the picture the browser decoded.
| File | Palette | Pixels changed | Largest change | PSNR |
|---|---|---|---|---|
| Screenshot | 128 colours | 53,328 (4.1%) | 70 of 255 | 43.4 dB |
| Photograph | 128 colours | 933,545 (48.6%) | 90 of 255 | 38.4 dB |
| Photograph | 32 colours | 1,119,218 (58.3%) | 111 of 255 | 32.7 dB |
| Logo | 128 colours | 15,151 (2.4%) | 76 of 255 | 54.5 dB |
| Gradient | 128 colours | 445,200 (61.8%) | 1 of 255 | 53.3 dB |
The last row is the useful surprise. On the gradient, 61.8% of the pixels moved, yet no pixel moved by more than one level and the PSNR is the second best in the table. It also produced a file 21% larger than the 3,785-byte original, because a palette of 128 colours turns a smooth ramp into a staircase of index values, and index values do not deflate as well as a linear ramp does.
Neither number tells you whether small text is still readable. Look at the preview. That judgement belongs to the picture, and the preview sits next to each card.
Transparency costs a table, not a channel
A truecolour PNG with alpha keeps four bytes per pixel. An indexed PNG keeps one alpha byte per palette entry, in the tRNS chunk, and every pixel that uses that entry gets that alpha. The palette therefore carries at most 256 alpha values, shared across colours.
On the 800 × 800 logo, 228,933 pixels are fully transparent, 156,942 are partly transparent (the soft shadow and the anti-aliased edge) and 254,125 are opaque. At 128 colours the alpha of 8,233 pixels changed; at 256 colours that fell to 5,250. The transparent background stayed transparent in both.
The lossless copy keeps the alpha channel exactly as decoded and weighs 39,876 bytes. One detail belongs in the open: drawing an image onto a canvas and reading it back premultiplies alpha and rounds, so on this logo 6,911 of 640,000 pixels end up one level away from the value stored in the original file. The lossless card means the same pixels the browser decoded, not the same bytes as the file.
The 16-bit file that gets bigger
A 900 × 600 greyscale PNG stored at 16 bits per pixel weighs 2,432 bytes. The browser decodes it to 8 bits per channel, so this page receives 256 levels of grey, and the lossless copy it writes is an 8-bit indexed PNG at 4,508 bytes, 85% larger than the source.
Two things are happening. The browser already threw away the extra precision before the tool saw the pixels, so no copy made here can be lossless against the original samples. And a 16-bit grey ramp compresses unusually well, because each row is almost identical to the one above it; replacing the ramp with palette indices destroys that predictability.
The tool prints the source bit depth and colour type above the cards for exactly this reason. When the source says 16-bit, treat the lossless card as lossless against the decoded picture. Expect it to lose.
What does not come along
Metadata does not survive either copy. An embedded ICC profile, a gamma chunk, an Exif block, text chunks: none are copied into the new file. The source line lists whichever ones the original had. An animated PNG is read as its first frame only, which the line also says.
For a screenshot or a logo that is usually fine. For a print asset with a calibrated profile it is not. Keep the original.
Why nothing leaves the tab
Three conversions in a row were watched through the browser's resource timing: no new entry appeared while the tool worked, on a 1,440 × 900 screenshot that takes about half a second. With the network switched off, the same file produced byte-identical output, checked by SHA-256 on both copies.
The page itself loads a stylesheet, one 34 KB script and the site's page-view tag before you drop a file. The picture is never among those requests.
What each control does
Drop one PNG, up to 40 megapixels. The colours slider moves only the second card, from 256 down to 2; the lossless card is always computed. Each card carries its own size, the change against the original, a preview, and a download. The palette card also states how many pixels changed, the largest change and the PSNR.
When a PNG is the wrong file
If the picture is a photograph and nothing needs to be transparent, a lossy format is the better tool: JPG and WebP were designed for exactly that content, and they will beat any palette PNG at the same visual quality. PNG earns its keep on flat colour, hard edges and transparency. Compressing a photograph as PNG is a way of paying for detail nobody can see.
Quick answers
What happens to the colours I drop? They are merged into the nearest palette entry that survives, chosen so the merged picture stays close to the original in RGB distance. Flat areas barely change; gradients and skin tones move first.
Can I name a target size in kilobytes? Not on this page. There is no size field here, only a colour count, and the file size that follows from it. If you need a hard limit, the image compressor takes a KB target and will trade away pixels to reach it.
Why is my palette copy bigger than the original? Because the palette replaced a pattern deflate liked with index numbers it does not. It happened to the gradient above: 3,785 bytes in, 4,571 bytes out, even though no pixel moved by more than one level.
Is the lossless copy byte-identical to my file? No. It is pixel-identical to the picture the browser decoded. Chunks such as the ICC profile, gamma and Exif are dropped, and semi-transparent edges can shift by one level in the canvas round trip.
Does an indexed PNG still open everywhere? Yes. Palette-based PNG has been part of the format since the beginning, and every browser, email client and design tool reads it.
What happens to an animated PNG? Only the first frame is read, and the copies are still images. The source line flags an APNG before you download anything.
Which card should I download? If the picture is a screenshot, an icon or a diagram, take the palette copy and check the preview at full size. If it is a photograph, or if a colour profile matters, take the lossless card when it is smaller and keep the original when it is not.