How to compress a PNG without losing any quality

“Without losing quality” appears on a great many compression tools, and it covers two promises that are not the same. One can be checked to the last bit. The other is a judgement about what your eyes will notice. This guide does the first, and is precise about where it stops.

What “without losing quality” can honestly mean

Lossless image compression is rewriting how an image is stored, meaning the filter applied to each scanline, the palette, the bit depth and the ordering of the compressed stream, without altering a single pixel value. The test is mechanical: decode the original and the result, compare every channel of every pixel, and they match. A PNG has a lot of room for this, because the format allows many valid encodings of the same picture and a general-purpose encoder is not trying to find the smallest.

The other promise is usually called “visually lossless”. It means a lossy result whose damage you are not expected to see at normal viewing size. That can be a fair trade, but it is an opinion about one image on one screen, not a property a byte-for-byte check can confirm. A common lossy approach for PNG cuts the image down to a palette of 256 colours or fewer; on a photograph with far more colours than that, it changes pixels by design.

So, to compress a PNG with no loss at all, you want an optimiser, not a re-encoder and not a colour reducer.

Doing it with the image compressor

1. Open the image compressor and press “Choose images”, or drop or paste your PNGs anywhere on the page. There is no limit on how many; each file becomes a card marked “Ready · oxipng, lossless”.
2. Leave “More options” closed: its summary line reads “PNG effort: Fast (level 2) · lossless at every level”. “Harder (level 4)” and “Hardest (level 6)” are inside if you want them. All three are lossless, which the note under them states.
3. Ignore the “JPEG quality · MozJPEG” slider. It only governs JPEG files, and the line under it says how many of those you added.
4. Press “Compress 1 image” (or however many you queued). Files run one after another, not in parallel, so a phone does not run out of memory.
5. Read each card: the size before and after, a percentage, and “identical pixels” for anything that went through oxipng. “Before and after” shows the original and the result side by side; with several files, pick a card to see another.
6. Download with “Download” on a single card, or with the button that replaced “Compress” (“Download all … as .zip” for a batch), which the bar at the foot of the screen also carries.

If a percentage turns red with a plus sign, that file came out bigger. It was already compact and there was nothing left to take, so keep your original.

The measurements

These figures come from the research behind the tool: the same pixels written three ways, then compared. The canvas column is what you get when a browser decodes the PNG and asks its own encoder to write it back, which is how most in-browser “compressors” work.

Image	Source PNG	Re-saved through a canvas	Optimised with oxipng	oxipng versus the source
Flat interface graphic	21,493 B	38,905 B (+81%)	3,350 B	−84%
Photograph, 1600 × 1000	1,006,774 B	1,236,423 B (+23%)	864,362 B	−14%

The oxipng figures are at its top level, and every pixel in both results matched its source. The flat graphic is the pleasant surprise: 21,493 ÷ 3,350 = 6.4 times smaller. The photograph is the realistic expectation for a picture with real tonal detail. Three test images is indicative rather than a benchmark suite, so treat the direction as firm and the exact percentages as one sample.

Effort buys search time, not pixels

The levels in the menu do not trade quality for size. Output is lossless at every level; a higher one simply searches longer for a smaller legal encoding. On the same photograph, natively and on one core:

oxipng level	Output	Time
2 (the tool’s “Fast”)	884,853 B	0.97 s
4 (the tool’s “Harder”)	870,679 B	1.98 s
max	864,362 B	3.45 s

The top level saved 20,491 more bytes than level 2 for three and a half times the work. In the browser, WebAssembly runs two to three times slower than those native timings, which is why the tool starts on the fast level.

What goes wrong: re-saving is not optimising

The canvas column in the first table is the failure this task invites. Re-saving a PNG through a browser’s encoder made the flat graphic 81% bigger and the photograph 23% bigger. The pixels were fine; the encoder simply was not trying. A tool built that way is an inflater on a real share of inputs, and if it only ever reports savings you may not notice.

Soft edges are a second trap. A canvas rounds half-see-through pixels on the way in, and that rounding cannot be undone on the way out. In the PNG to WebP measurements, a feathered photographic cut-out sent through a canvas at lossless quality came back with 39.77% of its pixels changed. The compressor’s PNG path avoids both problems by never touching a canvas: your bytes go straight into oxipng and its bytes come straight back.

It goes one step further than it strictly has to. oxipng can rewrite the hidden colour values under fully transparent pixels, which nobody can see and which saves real bytes, but which is not bit-identical. The tool leaves that option off (optimize_alpha is false in its source), because “identical pixels” is the claim on the screen.

Where lossless stops

• JPEG files go to MozJPEG, which is lossy. It throws detail away to save bytes, and the tool says so next to its slider. A JPEG cannot be made smaller in this tool without that loss.
• GIF and BMP come out as PNG. They are read once and written as an optimised PNG with no pixel altered, so the file extension changes.
• WebP and AVIF are refused, because both are already compressed better than a PNG or JPEG path could manage.
• Animated PNGs and GIFs are refused. Decoding an animation in a browser keeps only the first frame, which would turn a forty-frame GIF into a still and report it as a saving.

Other ways to do it

On the command line, oxipng itself:

oxipng -o 4 --strip safe image.png

-o 4 is the effort level, the same level as the tool’s “Harder” option, and this is the syntax our measurements were run with. --strip safe tells it to remove metadata it judges safe to drop; the pixels are untouched either way. Work on a copy if you want to keep the original file.

macOS and Windows have no built-in lossless PNG optimiser to point you to; the command line is the alternative.

Checking that nothing was uploaded

Open your browser’s developer tools on the Network tab before you press compress. The first run fetches the compression engine itself, a WebAssembly file served by this site; what you will not see is any request carrying your image out. Compress a second file and the engine is already loaded, so nothing new appears at all.

Drop your PNGs into the image compressor and read the per-file figures before you keep anything. If what you need is a different format rather than a smaller PNG, that is the image converter’s job.