How to Compress a PNG: Two Ways, Measured

How to compress a PNG comes down to two levers: lossless optimization, which re-packs the file and keeps every pixel exact, and lossy palette reduction, which cuts the number of colors and can shrink the file by 70 percent or more. Run the lossless pass first, then reach for palette reduction only if you still need it smaller.

I build the PNG compressor on this site, so this is the honest version of that choice: what the lossless side actually buys you, and where you need a second tool if the file has to be smaller than filtering and DEFLATE alone will manage. The compression mechanism here is the one every PNG encoder uses; PNG explained covers the whole format if you want more than the compression half. This page sticks to the two levers you pull and when to reach for each.

What makes a PNG compressible?

A PNG compresses in two stages, and only one of them is allowed to throw anything away. Getting the file smaller means knowing which stage you are working, because the two stages produce wildly different results.

Lossless: filtering and DEFLATE

The lossless stage predicts each pixel from its neighbors using one of five filter types, None, Sub, Up, Average, and Paeth, stores the small difference instead of the raw value, then runs the result through DEFLATE, the same general-purpose compressor behind a ZIP file (Wikipedia, PNG). None of that changes a single pixel; it only changes how efficiently the same pixels get packed. Choosing better filters and a tighter DEFLATE stream, plus dropping ancillary chunks like color profiles and text fields, is the whole lossless story. It is real savings, but it is bounded: there is only so much a smarter packer can do to pixel data that genuinely does not repeat.

Lossy: cutting the color count

The second stage is optional, and it is where the big savings live. Even though PNG is a lossless format, an encoder can preprocess the image in a lossy way first, quantizing a truecolor picture down to a smaller palette, often 256 colors, before the lossless stage ever runs. Fewer colors means fewer bytes per pixel, and DEFLATE has an easier job on whatever is left. That single decision, whether the color-count stage runs at all, is the entire gap between a PNG that is a little smaller and a PNG that is a lot smaller. This is what people mean by lossy PNG compression, and it is the reason a screenshot can drop by two thirds while a photo saved as PNG barely moves.

How to Compress a PNG in Your Browser, Step by Step

The fastest way to compress a PNG file is to drop it into a browser tool that re-optimizes the encoding and strips metadata in one pass, keeping every pixel and every alpha value intact. Nothing installs, and for a file an editor wrote lazily the byte count drops the moment you download the copy.

Here is the whole process with the PNG compressor on this site:

1. Open the tool and drag your PNG onto it. The work runs in your browser; the file is not sent anywhere you have to trust.
2. It re-optimizes the filter choice and the DEFLATE stream and strips metadata, EXIF fields, color profiles, and text chunks, automatically. Alpha transparency, if the file has any, is untouched.
3. Compare the before and after byte counts on the card. For an unoptimized source this alone trims a meaningful chunk; for a file already written efficiently, the gain is smaller.
4. Download the result. Every pixel is identical to the original; only the packing changed.

This route stays on the lossless side of the line on purpose. It repacks whatever pixels you hand it and never touches color depth, which means you can compress a PNG without losing quality at all, but it also means the cut is modest on a file that was already reasonably encoded. If you need the file meaningfully smaller than a lossless repack manages, you have a color problem, not a packing problem, and that is the next lever.

How does lossy PNG compression work?

Lossy palette reduction is where PNG compression genuinely competes with JPEG-sized savings, and it works by cutting how many colors a file may use rather than by discarding pixels outright. pngquant's own published example takes a 75,628 byte PNG down to 19,996 bytes, about 73 percent smaller, by converting it to an optimized palette of up to 256 colors while keeping full alpha transparency intact (pngquant). TinyPNG runs a similar smart-quantization approach through a web upload and removes metadata on top. The visual cost is usually close to invisible, because the quantizer picks the palette that best matches the original rather than a fixed set of colors.

The command line version is pngquant image.png, or with a quality window pngquant --quality=65-80 image.png, which skips files it cannot compress inside that quality range instead of wrecking them. The important part is that this is a separate step from the lossless repack: our browser tool does not quantize colors, so capturing the palette-reduction cut means running the file through pngquant or a web quantizer, ideally after a lossless pass has already stripped the easy weight.

The two methods at a glance

The two levers do different jobs, and the right one depends entirely on whether you can afford to lose color depth. Reference this before you pick a tool.

Read the table top to bottom and you are reading the order to try things in. Repack losslessly for free, safe savings on anything. Quantize only when you need the bigger cut and the file is a final copy, not a working master.

What is the best pipeline to reduce PNG file size?

The biggest way to reduce PNG file size on a graphic is to quantize the palette first, then run a lossless pass behind it. pngquant --quality=65-80 image.png gets the large palette-driven cut, and oxipng -o 4 --strip safe image.png behind it squeezes a little more out of whatever filter and DEFLATE overhead is left in the smaller file, at zero additional visual change (oxipng). Running the order backward wastes work: optimize an unquantized file first and the palette pass that follows rewrites the pixel data anyway, throwing away the DEFLATE tuning you just paid for.

oxipng's own documentation notes that higher optimization levels, up to -o 6 or max, are almost always smaller but not guaranteed to be on every file, and its optional Zopfli mode is not guaranteed to beat the default either. So -o 4 with --strip safe is a sensible default rather than reaching for the slowest setting out of habit. This lossy-then-lossless order is the same two-step pipeline image-optimization guidance recommends generally: an optional lossy filter that removes some data, followed by a lossless filter that compresses what remains (web.dev).

How do you compress a PNG on a Mac or Windows?

You can compress a PNG on either platform without a web upload, though the good desktop options differ. The mechanism is identical to the browser route; only the tool changes.

On a Mac

On a Mac the cleanest free option is ImageOptim, a drag-and-drop app that bundles several best-in-class optimizers and removes invisible junk like EXIF metadata, embedded thumbnails, and comments in one step (ImageOptim). Drop a folder of PNGs on it and it repacks each one losslessly in place. Preview can also re-export a PNG through File then Export, but Preview does not expose a real optimization level, so for pure size work ImageOptim is the better local tool. Neither touches the color count, so both stay on the lossless side unless you add a quantizer.

On Windows

Windows has no strong built-in PNG optimizer. The Photos app and Paint can re-save a PNG, but they do not meaningfully re-optimize the encoding, and Paint can strip transparency if you are not careful. The reliable routes on Windows are the browser tool for a lossless repack, or pngquant from the command line for the palette cut. If you only need fewer pixels rather than a better encoding, the Photos app or PowerToys Image Resizer handles the dimension change, which is often the largest saving of all on an oversized screenshot.

How do you compress a PNG in Photoshop?

In Photoshop the size lever lives in the export dialog, not the main Save command. Use File, then Export, then Export As, or the older File, then Export, then Save for Web (Legacy), which still gives the most direct control over PNG size.

The single most useful choice in that dialog is PNG-24 versus PNG-8. PNG-24 keeps full truecolor and is the safe default; PNG-8 reduces the image to a 256-color palette, which is exactly the lossy quantization pngquant does, and it can cut the file dramatically on a flat graphic or logo. Watch the file-size readout at the bottom of the Save for Web dialog as you switch between them, and check any soft gradient or drop shadow at 100 percent zoom before you commit, since PNG-8 is where banding shows up first. For a photograph, neither PNG setting will get close to what JPEG or WebP manages, which is the next section.

When should you convert a PNG instead of compressing it?

Convert the PNG when it is actually a photograph, because no amount of PNG compression closes the gap with a photo format. PNG's lossless floor means a photo saved as PNG typically runs five to ten times larger than the same photo saved as JPEG or WebP at a quality nobody could tell apart, and palette quantization does not help, because a camera's color noise defeats DEFLATE's pattern matching no matter how few colors the palette allows. A 4.5 MB scene that lands near 900 KB as a quality 80 JPEG can sit at several megabytes as a PNG and refuse to move.

So the honest rule is a format decision, not a compression setting. Keep PNG for logos, screenshots, line art, and anything that needs pixel-exact edges or transparency. For photographic content, convert: WebP typically runs 25 to 35 percent smaller than an equivalent JPEG, and AVIF often lands near 50 percent smaller, at the cost of slower encoding. The format swap beats any amount of PNG-side compression on a photo, and it is the one move most "my PNG is huge" problems actually need.

Other free wins before you quantize

Two moves shrink a PNG without touching color, and both are worth doing first. Resize if the image is larger than it will ever display: pixel count drives raw byte cost directly, so a screenshot saved at twice the size it shows is carrying twice the pixels for nothing. Strip metadata second; ancillary chunks ride along without affecting how the file looks, and a good optimizer removes them automatically. Neither move costs a visible pixel, and a lot of PNGs are still carrying both kinds of waste.

If you are chasing a specific cap like 100 KB or 50 KB, combine the levers in order. Resize to the real display dimensions, quantize the palette with pngquant, then repack losslessly. A flat graphic can hit 50 KB comfortably that way; a detailed one may only reach 100 KB before quantization starts to show, at which point resizing further is the honest fix rather than crushing the color count.