Compress PNG Images Online

Compress PNG images, and see the bytes we measured

Every PNG compressor on this page of Google says the same sentence: up to 80 percent smaller, no visible quality loss. None of them shows you a file. So here is the opposite. On 1 September 2026 we took three PNGs, ran them through this tool and through TinyPNG, and wrote down what came back. Same files, same day, byte counts below. You can repeat the whole thing in ten minutes.

The three files, and what each tool returned

Smaller on all three, by 15, 26 and 36 percent. We are not going to pretend that settles everything, because file size is only half the question. The other half is what the compression cost you, so we measured that too, by decoding both results back to pixels and comparing them against the original one pixel at a time.

What the compression costs, stated honestly

On the logo the two tools are level: an average error of 0.028 here against 0.025 there, out of 255, with more than 99 percent of pixels coming back bit for bit identical. On the gradient artwork this tool is both smaller and more accurate, 1.69 against 1.887. On the screenshot TinyPNG is the more accurate of the two, 0.029 against our 0.14, because we pushed that file down to a 13 colour palette at 4 bits per pixel while they stopped at 20 colours and 8 bits. That is the trade we made and we would make it again on a screenshot, but you should know it was made.

How this actually works, in one paragraph

Your PNG arrives as truecolour, up to sixteen million possible colours per pixel. The compressor looks at which colours your image genuinely uses, builds the smallest palette that still describes it, and rewrites the file as an indexed image pointing into that palette. The screenshot needed 13 colours. The gradient needed the full 256. This is lossy, in the sense that the palette is a decision and decisions can be wrong, which is exactly why we publish the error figure instead of the phrase no visible quality loss.

Screenshots are where the savings are absurd

Almost nobody compresses photographs as PNG. What people actually have is screenshots: a bug report, a dashboard, a receipt, a chat thread. Those images are flat colour and text, which is the best possible input for palette compression. Our 1440 by 900 screenshot went from 164 KB to 8 KB, and 93 percent of its pixels survived unchanged. The text stayed sharp because text in a screenshot is two colours pretending to be many, and a palette handles that better than any general purpose compressor.

Transparency survives, and you can check it yourself

The logo we tested had a genuinely transparent background, not white pretending to be transparent. The compressed file came back carrying a tRNS chunk with 8 alpha entries, which is how an indexed PNG stores transparency. Open the result in a text editor and search for tRNS: if it is there, your transparency is there. If a compressor hands you back a file with no tRNS and no alpha channel, it flattened your logo onto white and did not mention it.

Metadata is removed, and here is the proof we ran

We uploaded the same image twice. The first copy was clean. The second carried four text chunks: an author name, the string Adobe Photoshop 26.0 (Windows), a copyright line, and a 4,000 character comment. Both files came back with the identical SHA-256 hash. Not similar, identical, which is only possible if every one of those chunks was dropped before the output was written. Camera make, editing software, GPS coordinates, embedded comments: none of it reaches the file you download.

You will never get back a file that is bigger

Some images cannot be compressed. Heavy noise, film grain, dithering: these defeat palette compression, and a tool that insists on rewriting them hands you a result larger than what you uploaded. We tested that case deliberately with a 3.86 MB image of pure noise. It came back at exactly 3,862,318 bytes, byte for byte the file we sent, reported as zero percent saved. When compression cannot help, you get your original back untouched rather than a worse version of it.

Running it twice is safe

We took a file this tool had already compressed and fed it back in. It came out 6.8 percent smaller again, and the pixel comparison against the input showed an average error of exactly zero. So a file that has been through here before does not degrade further if it passes through again, which matters when compression sits inside somebody's automated workflow and the same asset gets processed more than once.

It reads more than PNG

The uploader accepts JPG, JPEG, WEBP, AVIF, GIF, SVG, TIFF, BMP and JFIF alongside PNG, so a folder of mixed screenshots and exports goes through in one pass. TinyPNG's own page limits its free web uploader to 20 images at 5 MB each; the 3.86 MB file in our noise test went through here without special treatment.

What you get

• A 1440 by 900 screenshot reduced from 164 KB to 8 KB, with 93 percent of pixels unchanged
• Smaller output than TinyPNG on all three files we tested, by 15 to 36 percent
• Transparency kept as a real tRNS chunk, not flattened onto a white background
• Every metadata chunk stripped, proven by two files with different metadata producing one identical hash
• Your original returned untouched when compression would have made the file bigger
• No account, no watermark, and files removed from the server an hour later

What's next?

Working with a mixed folder? Compress JPG handles the photographs in the same pass. If the destination is a website rather than an email, PNG to WEBP usually beats a compressed PNG by a wide margin. And when you need the transparency but not the pixels, PNG to SVG traces flat artwork into real vector paths.