ALL IMAGE TOOLS56
Compress PNG
Compress PNG Online — Lossless, Free & Private
Real PNG re-compression in your browser: fewer bytes, identical pixels, and an honest number when there is nothing left to win.
Enforced: 12 megapixels and 48 MB of decoded image. oxipng holds the decoded raster in wasm memory, and a browser tab cannot give it back.
About Compress PNG
Re-encoding a PNG through a canvas is not compression: the Canvas API has no compression level, no filter strategy and no palette knob anywhere in it, so a picture decoded to pixels and written back out often comes back larger than it went in. That round trip is not what happens here. This page runs oxipng 9.1.1, compiled to WebAssembly and served from this site, which searches PNG filter strategies and re-deflates the image data. Nothing is re-drawn, so every pixel comes out identical. How much you save depends entirely on what wrote the file. A PNG exported by a browser, a screenshot tool or a design app typically comes down 20–35% — measured at 31.5% on this site's own 1200 × 630 Chromium-rendered social image at level 2, and 35.2% at level 4. A PNG that has already been through pngcrush, oxipng or an exporter set to maximum compression comes down 0–3%, and in that case oxipng hands your file straight back byte for byte; the page says so plainly instead of pretending to have done work. A photograph saved as PNG is the worst case, measured at 8.5–9.6%, and the honest answer there is to convert it to WebP or JPEG rather than to squeeze the PNG. Effort levels 1 to 4 are offered and 5 and 6 are not, because they were measured returning byte-identical output to level 4 for roughly twice the time. Level 2 is the default: it does most of the work for a fraction of the wait. One optional switch rewrites fully-transparent pixels, which is the only thing on this page that changes a pixel value — and only pixels whose alpha is zero, which nothing can display. Input is capped twice, because the heap tracks the decoded picture and not the file on disk: 12 megapixels, and 48 MB of decoded raster. Depth costs what a pixel count cannot see — two real 4000 × 3000 exports measured 372 MB and 751 MB, at a size the first cap admits — and a browser tab never gets that memory back. The whole run is a single pass with no progress signal, so the page shows an indeterminate bar rather than a fabricated percentage, and reports the time the run actually took when it finishes. Nothing is uploaded; the engine runs in this tab.
Questions
How much smaller will my PNG actually get?
It depends on what wrote the file, and the range is wide enough that a single number would be a lie. A PNG exported from a browser, a screenshot tool or a design app typically comes down 20–35%: this site's own 1200 × 630 social image, rendered by Chromium, went from 171,221 bytes to 117,326 at level 2 (31.5%) and 110,876 at level 4 (35.2%). A PNG that has already been optimized comes down 0–3%. A photograph saved as PNG is the worst case measured, at 8.5–9.6%. The page shows the number it actually achieved on your file, not a promise made before the run.
Is it really lossless, or is that marketing?
It is lossless. oxipng re-encodes the image data — it searches filter strategies and re-deflates — without ever decoding to pixels and re-drawing, so every pixel round-trips. You can check it yourself: the compare view on the page has a DIFF tab that computes a real pixel difference between your original and the result, and for a lossless run it is black everywhere. One thing does change and is worth knowing about: oxipng rewrites the pixel format when the image does not use it, so an all-opaque RGBA image can come back as greyscale or as a palette image. The pixels are the same; the encoding of them is smaller. The page reports the before and after format whenever it changes.
What does it mean when the tool gives my file back unchanged?
It means there was nothing left to win, and it is a normal outcome rather than a failure. oxipng never returns a bigger file; when its search cannot beat what is already there, it returns the input byte for byte. That happens to any PNG that has been through pngcrush, through oxipng before, or through an exporter set to maximum compression, and 0–3% is the whole range available on a file in that state. The page tells you and hands you your original rather than inventing a saving.
Why do the effort levels stop at 4?
Because 5 and 6 do not buy anything. Measured on this site's own social image, levels 4, 5 and 6 all produced exactly 110,876 bytes — byte-identical output — while taking 2.3 s, 4.5 s and 5.5 s respectively. Offering them would sell twice the wait for zero bytes. Level 2 is the default because it is the best bytes-per-second of the four; level 4 is the knee, worth it when you care about the last few percent more than the wait.
Why is there a 12-megapixel limit, and why is the progress bar not a percentage?
Both come from how the engine works. oxipng's WebAssembly heap was measured at roughly eight times the decoded picture and WebAssembly memory can never shrink, so a large image leaves a high-water mark that stays for the life of the tab — about 300 MB at 12 megapixels of 8-bit colour, and 372–751 MB measured on deeper 4000 × 3000 exports. That is why two limits are enforced rather than one: 12 megapixels, and 48 MB of decoded raster. And the codec is a single synchronous call that reports nothing until it returns, so there is no progress to display — the bar is indeterminate rather than fabricated. Throughput was measured at roughly 570 ms per megapixel at level 2, which makes a 12-megapixel file about a five-second job, and the page reports the time your run actually took.
Is my file uploaded to a server?
No. Transmute processes everything locally in your browser using JavaScript and WebAssembly. Your files never leave your device — there is no server, no upload, no cloud processing.