Why is my PNG only shrinking 10% — I expected more?

Lossless re-encoding gain depends entirely on how well the source PNG was already optimised. Modern image editors (Adobe Photoshop, Affinity, Sketch) often produce decently-optimised PNGs by default, leaving little room for further DEFLATE wins. PNGs exported from the web (right-click → Save As) tend to come from already-optimised servers. Larger gains (20–30%) typically come from PNG screenshots from older OS tools, PNGs exported from poorly-configured tools, or files explicitly saved at low compression for speed. If you need substantial size reduction on a PNG, the right answer is usually 'this content shouldn't be PNG' — convert to JPG (for photos) or WebP (for both photos and graphics) instead.

Compress PNG Online — Lossless DEFLATE Re-encoding via UZIP

Q: How can a PNG get smaller if it's already lossless?

PNG (W3C 2nd Edition, 10 November 2003 / ISO/IEC 15948:2004) is lossless but the file size depends on encoder choices that aren't fixed by the spec: which of the 5 filter types (None, Sub, Up, Average, Paeth) is applied per scanline, and what zlib compression level (1–9) is used for the DEFLATE step (RFC 1951 Deutsch, May 1996). A naive PNG encoder picks defaults that produce a working file but not the smallest possible. browser-image-compression's UZIP path (used by this tool) re-encodes with optimised filter selection and higher zlib level, typically saving 5–30% with zero pixel changes. Every pixel value remains bit-exact identical to the input.

Q: Is this tool lossless or lossy PNG compression?

Strictly lossless. The pipeline is decode-PNG-to-pixels → re-encode-via-UZIP-DEFLATE with no quantisation step. Every pixel value is preserved bit-exact. For lossy PNG compression with palette quantisation (32-bit RGBA → 8-bit indexed PNG, savings up to 70%) you'd need a tool using libimagequant/pngquant (Kornel Lesinski, ImageOptim project, GPL-3.0) — but pngquant changes the colour values by mapping them to a reduced palette, which is visually indistinguishable for many images but technically lossy. This compress-png tool does NOT do palette quantisation; if you need that level of size reduction, use a desktop pngquant or convert to WebP/AVIF instead.

Q: Does the quality slider affect PNG output?

No, the quality slider has no effect on PNG. PNG is lossless by spec — there is no quality knob to turn. The size variation comes from filter selection (5 types per scanline) and DEFLATE compression level (1–9). browser-image-compression's UZIP path picks optimised values automatically; you don't control them. If your tool UI shows a quality slider for PNG input, that's typically only meaningful when the user converts the PNG to a different format (JPG, WebP) — for pure PNG-to-PNG re-compression, the slider is informational only.

Q: Does PNG transparency survive compression?

Yes, exactly. PNG (W3C 2nd Edition) supports both per-entry alpha for indexed-colour PNG (tRNS chunk) and full 8-bit alpha (RGBA mode). The tool's UZIP-based DEFLATE re-encoding preserves every alpha byte bit-exact — no compositing, no flatten, no alpha downconversion. This is unlike PNG → JPG conversion (where alpha must be flattened against a background) or PNG → WebP (where alpha is preserved but the format changes). PNG-to-PNG re-compression is the safest possible operation for transparency-heavy content (logos, icons, screenshots with alpha).

PNG Compressor — Lossless DEFLATE Re-encoding (RFC 1951)

PNG (W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004) is lossless by design — DEFLATE compression (RFC 1951 Deutsch, May 1996, LZ77 + Huffman with 32 KB sliding window) preserves every pixel exactly. The compression gain comes entirely from encoder choices not fixed by the spec: which of 5 filter types (None, Sub, Up, Average, Paeth) is applied per scanline, and what zlib compression level (1–9) is used for the DEFLATE step. browser-image-compression's UZIP path (Vanc, photopea, MIT licence) re-encodes losslessly with optimised filter selection and higher zlib level than naive PNG encoders, typically saving 5–30% with ZERO pixel changes — every pixel value remains bit-exact identical to the input. Critical: this tool does NOT do palette quantisation (which would be lossy). For lossy PNG with up to 70% size reduction via 32-bit RGBA → 8-bit indexed conversion, you'd need libimagequant/pngquant (Kornel Lesinski, ImageOptim project, GPL-3.0).

How to compress a PNG

Drop a .png file onto the tool or click to browse — single file or batch.
The tool routes through UZIP DEFLATE (bypassing Canvas which produces unoptimised PNG).
Quality slider has NO effect — PNG is lossless. Output size depends on filter selection + zlib level (auto-selected).
Review before/after sizes (typical: 5–30% reduction depending on source PNG optimisation level), then download.

Common use cases

Optimising PNG screenshots before uploading to a documentation CMS — typical 10–25% size reduction.
Trimming PNG logos and icons for web use without lossy conversion — preserves crisp edges and exact colours.
Reducing transparent UI assets (cursor sprites, Figma exports) for app bundles where every byte counts.
Re-optimising PNGs from older CMS exports or low-effort design-tool outputs that left compression on the table.

Frequently asked questions

How can a PNG get smaller if it's already lossless?

PNG (W3C 2nd Ed) is lossless but file size depends on encoder choices not fixed by spec: which of 5 filter types per scanline + zlib compression level. UZIP-based re-encoding (browser-image-compression's PNG path) optimises both, saving 5–30% with zero pixel changes.

Is this tool lossless or lossy PNG compression?

Strictly lossless. Pipeline is decode-PNG-to-pixels → re-encode-via-UZIP-DEFLATE. Every pixel preserved bit-exact. For lossy PNG palette quantisation (up to 70% savings) you'd need libimagequant/pngquant (GPL-3.0) — this tool does NOT do that.

Why is my PNG only shrinking 10%?

Lossless re-encoding gain depends on how well the source was already optimised. Modern editors (Photoshop, Affinity) produce decently-optimised PNGs by default. If you need substantial reduction, convert to JPG (for photos) or WebP (for graphics with alpha) instead.

Does the quality slider affect PNG output?

No. PNG is lossless by spec. Size depends on filter selection (5 types per scanline) + DEFLATE compression level (1–9). UZIP picks optimised values automatically.

Does PNG transparency survive compression?

Yes, exactly. PNG (W3C 2nd Ed) supports 1-bit tRNS + full 8-bit RGBA. UZIP DEFLATE preserves every alpha byte bit-exact — no compositing, no flatten. PNG-to-PNG is the safest possible operation for transparency-heavy content.

Why PNG compresses less than JPG — and when 'small enough' isn't

PNG's lossless mandate is both its strength and its size ceiling. The DEFLATE algorithm (RFC 1951) achieves typical 5–30% lossless re-encoding gains over poorly-optimised PNG sources, but cannot approach JPEG's 40–70% reductions because it cannot discard any information. The 5 filter types per scanline (None, Sub, Up, Average, Paeth) work by predicting each byte from neighbouring bytes and encoding only the difference — well-chosen filters expose patterns that DEFLATE compresses tightly, but no filter selection can compress an inherently complex image arbitrarily. Modern image editors (Adobe Photoshop, Affinity, Sketch) typically produce decently-optimised PNGs by default, leaving little room for further DEFLATE wins. Larger gains (20–30%) come from PNG screenshots from older OS tools, PNGs exported from poorly-configured CMSes, or files explicitly saved at low compression for speed. If your PNG is photographic content saved as PNG (a common but suboptimal choice in design workflows), the right answer is usually 'this content shouldn't be PNG' — convert to JPG (for photos) or WebP (for both photos and graphics, with alpha support) for substantial size reduction. The widely-used browser-image-compression library (Donaldcwl, MIT licence) bypasses Canvas entirely for PNG — Canvas's PNG encoder produces unoptimised output — and uses UZIP, a pure-JavaScript DEFLATE implementation, for compression that approaches what server-side tools like zopflipng or oxipng achieve. PNG transparency (1-bit tRNS palette or full 8-bit RGBA alpha) is preserved bit-exact through the round-trip; no compositing, no alpha downconversion.

Lossless DEFLATE re-encoding via UZIP (RFC 1951 Deutsch, May 1996)
Optimised filter selection (None, Sub, Up, Average, Paeth — 5 types per scanline per W3C 2nd Ed)
Higher zlib compression level than naive Canvas-based PNG encoders
Alpha channel preserved bit-exact (tRNS chunk + 8-bit RGBA mode)
Real-time size comparison with percentage savings
browser-image-compression library + UZIP.js (photopea, MIT) — no palette quantisation, strictly lossless

Free. No signup. No file uploads. Ads via AdSense (consent required).

Sources (5)

W3C (PNG Working Group) (2003). Portable Network Graphics (PNG) Specification (Second Edition). W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004 — PNG is lossless by design (5 filter types per scanline + DEFLATE compression); compression here is lossless re-encoding with potentially better filter selection.
Deutsch, P. (1996). DEFLATE Compressed Data Format Specification version 1.3. RFC 1951, IETF (May 1996, Aladdin Enterprises) — LZ77 + Huffman with 32 KB sliding window; PNG IDAT compression algorithm; browser-image-compression's UZIP path re-applies DEFLATE with potentially higher zlib compression level.
Kutskir, I. (Photopea) (live). UZIP.js — JavaScript DEFLATE/INFLATE. github.com/photopea/UZIP.js (MIT license) — pure-JavaScript DEFLATE implementation by Photopea founder; used by browser-image-compression for PNG re-compression in browsers without native server-side optimisers.
WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext (toBlob('image/png') is universally supported but produces unoptimised output; browser-image-compression bypasses Canvas for PNG and uses UZIP for better compression).
Donald (Donaldcwl) (live). browser-image-compression. npm package v2.0.2 (github.com/Donaldcwl/browser-image-compression, MIT) — UZIP-based PNG re-encoding pipeline used by this tool (lossless DEFLATE re-encoding, NOT palette quantisation).

These are the W3C, ISO/IEC, ITU-T, and IETF specifications the tool implements or builds on. Locate them on w3.org, iso.org, itu.int, or datatracker.ietf.org.