Short answer
Lossless PNG compression stores exactly the same pixels in fewer bytes, and every PNG already uses it: the format squeezes its data with deflate before it is ever written. A lossless optimiser can only repack that data better, which usually saves a few percent and up to about a third on a file an app saved carelessly. Anything larger comes from changing the picture: fewer pixels, or fewer colours. getPNG's compressor is of that second kind, so it is not a lossless tool.
If you searched for lossless PNG compression hoping for a way to cut a PNG to a fifth of its size without changing a pixel, there is a short answer and it is disappointing: there is no such way. A PNG is already losslessly compressed the moment it is saved, so the most a lossless tool can do is repack the same data a little more cleverly. That is worth a few percent, sometimes a third, and not more.
This page explains what lossless means for a PNG, where a lossless optimiser finds its saving, and where every larger saving really comes from. It also says plainly that getPNG’s own compressor, at /compress-png, is not a lossless tool: it reduces colours, which changes pixels, and the guide covers why that is usually the better trade for a transparent picture. If you only want a smaller file and do not mind how, how to compress an image is the wider starting point.
What lossless means
A compression method is lossless when decoding the result gives back exactly the numbers that went in. A zip file is lossless, which is why you can zip a spreadsheet and open it with every cell intact. A JPG is lossy: it throws away detail the eye is unlikely to miss, and what comes back is close to the original but not the same.
PNG is on the lossless side by design. A picture is a grid of pixels, each stored as numbers for red, green, blue and, on a transparent picture, alpha. A PNG stores those numbers, packs them, and on opening unpacks them to precisely the same values. Nothing about the compression changes a colour, an edge or a shade of transparency. The alpha channel guide explains why that last number matters so much on a cutout, and why a format that keeps it exactly is the right one for the job.
The word is easy to hear as “the file is untouched”, and that is the first thing to correct. A lossless step may rewrite every byte of the file. What it promises is only that the pixels it describes are unchanged.
Why every PNG is already compressed
When a PNG is written, two things happen to the pixel data before it reaches the file.
The first is filtering. Each row of pixels is replaced by the differences between it and a prediction made from the pixels beside and above it. A smooth sky stops being a thousand slightly different blues and becomes a long run of tiny differences, which are mostly the same small number. The PNG format offers five ways to predict a row, and the encoder is allowed to choose a different one for each row.
The second is deflate, the same method used inside zip files. It finds repeated runs in the filtered data and stores each repeat as a short reference to the first. Where the data repeats a lot, the file is tiny. Where it does not, there is little for deflate to refer back to.
That is the whole mechanism, and it explains the pattern everybody notices. A screenshot, a logo or a flat illustration is full of repeated colours and straight edges, so it filters and deflates to a small file. A photograph has noise and gradients in every pixel, so the same two steps get little out of it, and the file is large. A picture of a person with their background removed is still photographic detail on the subject, which is why a cutout in PNG form is heavy however it was made. Why a PNG is so large goes through the other things that add to it, from sixteen bits per channel to metadata.
Where a lossless optimiser finds its saving
If PNG is already compressed, what is a lossless optimiser doing? It is not compressing the picture a second time. It is redoing the first compression with more patience.
An app that saves a PNG in a fraction of a second has made quick choices. It has picked one filter for the whole picture, or a cheap guess for each row, and asked deflate for a fast setting. An optimiser tries many combinations of filters and deflate settings on the same pixels and keeps whichever gives the smallest file. It can also drop things that do not describe the picture: text notes, an editing history, a thumbnail, a colour profile that is not needed, or an alpha channel on a picture that is fully opaque everywhere.
Two honest limits follow from that.
The ceiling is low. The pixels are fixed, so the best any arrangement can do is bounded by how much repetition those pixels contain. A few percent is a typical result on a PNG that was saved with care, and up to about a third on one written quickly by an app, which is the range the PNG size guide gives for tools such as oxipng. Screenshots and flat artwork lean towards the better end, and photographs towards the worse.
Running it twice does nothing. Once the best arrangement has been found, it is the best arrangement. A second pass over the same file finds the same answer. This is the opposite of a lossy format, where each pass costs a little more quality.
One more caution. Some optimisers offer an option that changes the colour values hidden under fully transparent pixels, because nobody sees them and they compress better when they are all the same. The documentation for oxipng notes that this is technically lossy even though nothing visible changes. It is a fair trade, but it is a reminder to read what a tool means by lossless before relying on the word.
Where the big savings really come from
Everything that takes a PNG to a half, a fifth or a tenth of its size changes the picture in some way. There are only four ways to do it.
| What changes | Typical effect | Pixels changed? |
|---|---|---|
| Fewer pixels (resize) | About three quarters gone for every halving of the width | Yes, permanently |
| Fewer colours (a palette) | Often half or more of what is left | Slightly, usually invisibly |
| A different format (WebP, JPG) | A large saving, depending on the format and quality | Only if the new format is lossy |
| A lossless optimiser | A few percent, up to about a third | No |
The table is ordered by how much each is worth, not by how clean it is, and the cleanest option is last. That is the reason for reducing an image’s file size, lever by lever: the levers that change the picture are the ones that pay, and the lossless one is the polish at the end.
The arithmetic behind the colour lever is worth seeing once. A transparent PNG stored the usual way keeps four bytes for every pixel before compression: one each for red, green, blue and alpha. A picture of 1,000 by 1,000 pixels is a million of them, so four million bytes of raw data. The same picture stored with a table of at most 256 colours keeps one byte per pixel plus the table, so a little over a million bytes of raw data, before deflate has looked at either. That is a four to one reduction in what deflate starts with, and it is why colour reduction beats any amount of repacking. It is also why it is not lossless: a picture with tens of thousands of colours has been mapped on to 256.
Where getPNG’s compressor sits
getPNG’s compressor is the colour-table kind. It rewrites a picture with a colour table instead of a colour for every pixel, which is where a PNG’s size goes. It chooses the palette per file: it asks what 256 colours would achieve on that picture and takes the smallest palette within a tenth of it, so flat artwork lands on a small palette and a photograph on the full 256. It keeps a cutout’s soft alpha edge rather than snapping it to on or off, never resizes the picture, and never returns a file larger than the one you gave it. A file it cannot make smaller comes back untouched, and the page says so.
So the honest description is that it is lossy, in the gentle way most people want for a transparent picture, and that it is not a lossless optimiser. If an exact copy matters, because the file is a master, a print original or something you will edit again, keep the original and compress a copy. If you do want a lossless pass, the tools named in the PNG size guide do exactly that, and the order that guide gives is the right one: resize, then reduce colours, then optimise losslessly last.
Nothing is uploaded either way: the compression runs in your browser, on your own device.
See how little a lossless pass has to work with
- Pick two PNGs: a screenshot or a logo, and a photographic cutout. Note the size of each.
- Drop both on /compress-png and read the size it reports for each.
- Zoom to 200 percent on the soft edge of the cutout in the original and in the result.
You should see: the screenshot or logo shrinks a great deal, because flat colour reduces to a small palette with no visible change. The photographic cutout shrinks too but needs a much bigger palette, and its result is the one worth checking closely at the edge.
If you do not: if a file comes back unchanged, it was already as small as a colour table could make it, which is the result the page is designed to report honestly. Only resizing or a different format will help it.
Choosing between them
A short way to decide, once you know what the PNG is for:
- A master copy you will edit again. Stay lossless: keep the PNG as it is, or run a lossless optimiser if the file is oddly large. Do not reduce its colours.
- A transparent picture going on a page or into a document. Resize to the size it is shown at, then reduce its colours, which is where the saving is. The change is usually invisible and the file is a fraction of the size.
- A web page. Consider WebP instead. Google’s WebP documentation says lossless WebP images are 26 percent smaller than PNGs, and every current browser displays it.
- A photograph with no transparency. Neither lossless route gets close to a JPG. Convert it.
- A hard size limit on an upload form. That is a different search: compressing an image to an exact size covers the size limit mode, which looks for the largest palette that fits.
When expectations and results disagree
A few situations send people looking for a lossless trick that does not exist.
The file is a photograph saved as a PNG. It will be large however it is repacked. The format is the problem, not the settings, and the photo file formats guide sets out the comparison.
The picture is much bigger than it is shown. A 4,000 pixel wide picture displayed at 800 carries twenty-five times the pixels anyone sees, and no lossless step removes them. Resizing does, and it is the one step that cannot be undone, so it belongs on a copy.
The PNG looks worse than the photograph it came from. Lossless is not the cause. Either a tool reduced the colours or the size before saving, or the picture was a JPG first. A PNG made from a JPG keeps the JPG’s blocks and smears exactly: the format cannot restore what an earlier lossy save discarded, which is also why converting a JPG to PNG makes the file bigger and the picture no better. A PNG with a see-through look may also not be transparent at all: a fake transparent PNG shows how to tell.
Transparency is the reason it is large. It is usually not. A big area of fully transparent pixels compresses to almost nothing, and what costs space is the subject and its soft edge. What a transparent background is explains how that area is stored.
The free way
The lossy half, kept gentle
getPNG’s compressor reduces a picture to the smallest colour table that still matches it, keeps a cutout’s soft edge, and handles a whole folder at once, with nothing uploaded. It changes pixels slightly, which is where the saving comes from, so keep the original if you need an exact copy.
The short version
A PNG is already lossless and already compressed, so lossless PNG compression can only repack the same pixels, worth a few percent and rarely more than a third. The savings people actually want come from fewer pixels, fewer colours or a different format, all of which change the picture. Keep the original, do the changing on a copy, and use a lossless pass last if the file still looks heavier than it should.
Questions
Is a PNG already compressed?
Yes. PNG compresses its pixel data with deflate, the same method a zip file uses, before it writes a single byte, and it does so without discarding anything. That is why a PNG of a flat graphic is small and a PNG of a photograph is large: the method rewards repetition, and a photograph has very little of it.
Can you compress a PNG without losing quality?
Yes, but not by much. A lossless optimiser rewrites the same pixels with better settings, and the saving is usually a few percent, rising to about a third on a file that was saved quickly by an app. If you need half the size or less, something about the picture has to change: its dimensions, its colours, or its format.
Is PNG lossy or lossless?
The format is lossless: whatever pixels go in come out identical. A PNG can still look worse than the original photograph, but that happens before it is saved, when a tool reduced the colours or the size, or when the picture had already been through a JPG. The PNG itself is a faithful copy of whatever it was given.
Does compressing a PNG with getPNG change the pixels?
Yes. getPNG's compressor rewrites a picture with a colour table instead of a colour for every pixel, which reduces the number of colours, so it is lossy. It keeps the soft alpha edge and chooses the palette per file, but it is not a lossless optimiser and does not claim to be. A file it cannot make smaller is handed back untouched.
How much smaller can lossless compression make a PNG?
Usually a few percent on a PNG that was saved with care, and up to about a third on one saved quickly by an app. Screenshots and flat artwork tend to sit at the better end, photographs at the worse. It is a modest saving by design: the pixels have to survive exactly.
Is lossless PNG compression better than WebP?
For file size on a web page, usually not: Google's WebP documentation says lossless WebP images are 26 percent smaller than PNGs. PNG is still the more widely readable format outside browsers, in documents, print services and older apps, which is the reason to keep one.