How to Compress PNG Files Without Losing Quality

Compressing a PNG without losing quality means re-encoding the same pixels into a smaller container, which lossless optimizers like oxipng typically do at 10 to 40 percent savings. Getting dramatically more than that, 60 to 90 percent, requires changing the pixels, either by converting to WebP or JPG or by resizing. The honest framing matters: lossless and lossy are different tools for different jobs, and this guide shows where each one pays off.

The compress tool on this site runs both routes locally in your browser.

What lossless PNG compression actually does

A PNG file is a container of pixel data passed through two stages: a filtering step that turns the pixel grid into a more predictable stream, and DEFLATE compression, the same algorithm ZIP uses. Neither stage discards information, so any two PNGs of the same image contain identical pixels even when their file sizes differ.

Given that, why do file sizes differ at all? Because the encoder's choices matter: which filter it picks per row, how hard the DEFLATE stage searches for repeated patterns, and how cleanly metadata is stripped. Fast encoders pick conservative settings; optimizers like oxipng brute-force better filter combinations and deeper searches. The pixels are untouched, which is why optimizing an already-tight file saves almost nothing, while a file exported from a careless tool can shrink by a third.

That is the honest ceiling of lossless: meaningful but modest. When a file must become a fifth of its size, the pixels have to give.

The lossy routes, and what each one costs

Convert to WebP. WebP supports transparency and lossy encoding, and at around quality 75 to 85 it typically matches JPG's visual quality at a smaller size. For screenshots with text, stay at 85 or above. This is usually the best trade for web images, and it is what Auto mode picks most often.

Convert to JPG. Reliable and universally compatible, but transparency is gone: the format has no alpha channel, so transparent regions flatten to the background color. For photos this is fine; for logos it is not.

Resize. Often the biggest lever and the most ignored one. A 4000-pixel-wide screenshot displayed at 800 pixels carries 96 percent of its bytes uselessly. Halving both dimensions removes three quarters of the pixels. Chaining the resize tool before compression routinely beats any encoder setting change.

One property worth protecting: transparency. Auto mode in the compress tool never silently flattens an alpha image to JPG. It compares optimized PNG against WebP and keeps the smaller result with the alpha channel intact.

A workflow that holds up

For a folder of mixed screenshots and photos, the sequence that works is:

1. Cap the width first. Decide the largest width you will ever display (1920 is a sane default for full-width web images) and resize anything wider down to it. This step alone often halves the folder's total bytes.
2. Run Auto compression. Let the tool compare optimized PNG, WebP and JPG per file and keep the smallest honest result. Flat-color screenshots usually land as optimized PNG or WebP; photos land as WebP.
3. Spot-check text. Open one screenshot with fine text from the compressed set. If the letters look fizzy, raise quality to 85 or 90 for that batch, or keep those files as optimized PNG.
4. Download as ZIP and replace the originals.

For images heading into a merged output, compress first: smaller inputs make lighter merged files and much lighter PDFs, since PDFs embed images at full size.

The upload question

Most PNG compressors, including the well-known ones, are upload services. The file goes to a server, gets optimized there, and comes back. For public assets like blog images, that is a reasonable convenience.

For anything else, client files, screenshots with customer names in a corner, medical or insurance scans, the calculus changes. A compressor that runs in the page cannot leak what it never receives. It also has no queue, no file-count cap, and no deletion window to read about. The tools here follow that model, and like the rest of the site they keep working with the network disconnected.

There is a speed argument too. A 30 MB batch on a slow uplink spends real time traveling to a server and back. Locally, it never travels at all.

Why one PNG can shrink 90 percent and another barely 5 percent

Content decides. A flat-color UI screenshot with large uniform areas is DEFLATE's favorite meal: huge runs of identical bytes, compressing extremely well, and WebP's block prediction does even better. A detailed photograph as PNG is high-entropy noise from the compressor's perspective, and lossless tools can barely dent it. That same photo as WebP or JPG compresses enormously, because lossy compression is designed around how human vision tolerates approximation in noisy detail.

So if your PNGs are photos, expect lossless optimization to disappoint and conversion to carry the job. If they are screenshots, expect the opposite.

FAQ

Is PNG compression lossless or lossy?

PNG as a format is always lossless. Optimizing it with oxipng is lossless too. Lossy savings come from converting to WebP or JPG, or from resizing, both of which change pixels.

How much smaller will my PNG get without quality loss?

Typically 10 to 40 percent from lossless optimization, depending on how inefficiently the file was originally encoded. Files from careful exporters sit near the bottom of that range.

When should I accept lossy compression?

When the image is destined for a screen, not an archive, and size matters more than pixel-exactness. WebP at 85 is visually transparent for most content and dramatically smaller.

Does compressing remove transparency?

Not here. The tool never auto-converts alpha images to JPG. Transparency only flattens if you explicitly choose JPG output for an image that has it.

What quality setting should I use?

75 for photos, 85 to 90 for screenshots containing text, and lossless PNG when the file must survive future editing generations.

Should I compress before or after merging?

Before, for smaller outputs. Compressed inputs produce a lighter merged file and a much lighter PDF, since the PDF embeds each image at its full encoded size.