Compress PNG

Compress PNG shrinks PNG files through two routes. The first is a lossless re-encode that keeps every pixel identical while cleaning the file's internal structure and metadata. The second is an optional WebP export that trades the strict lossless guarantee for far smaller files, including full support for transparent areas. Both paths run locally in the browser, and both leave every transparent pixel exactly where it belongs.

The tool is built for the corners of the web where PNG still dominates. Screenshots awaiting documentation, logos that must sit on any background color, transparent product cutouts, contact sheets and archival graphics all live in PNG because the format guarantees pixel-perfect redelivery. That guarantee has a price - the files tend to be heavy - and this tool pays that bill down as far as lossless compression allows, then offers the WebP path for anyone who needs a more aggressive reduction.

The honest starting point is a constraint: PNG is a lossless format, so the size of the pixel data cannot be reduced without altering it. Lossless compression works by removing redundancy - unused palette entries, needless metadata, inefficiently arranged chunks - and once those are gone, further savings require a different format. That is precisely the decision the tool surfaces: keep the output as a lossless PNG for fidelity, or convert to lossy WebP for size, with transparency preserved in both cases.

For PNGs that contain photographic detail, the WebP route is usually the deciding factor. A photographic PNG exported by a tool that defaulted to PNG can be several times larger than the same image in JPEG-class compression, and WebP closes most of that gap while keeping alpha. For flat-color graphics and screenshots, the lossless pass is often all that is needed, and the quality slider stays out of the way because there is nothing lossy to tune.

Privacy is the same story as every tool in the suite: the file is decoded in browser memory and never uploaded, so screenshots of internal systems and unreleased interfaces stay on the device. Two boundaries keep expectations realistic. A source file is limited to roughly 25 MB, and the tool optimizes what is there rather than resizing or cropping - if a PNG also needs to be smaller in dimensions, pair this tool with a resize step before or after compression.

A PNG file is a stack of chunks around one essential payload: a stream of scanlines that describes every pixel. The encoder compresses that stream with the DEFLATE algorithm, the same one that powers ZIP files, which is why PNG behaves less like a codec and more like a compressed archive of raw image data. The room to shrink a PNG is therefore the room you can find inside that DEFLATE stream plus whatever structure surrounds it.

The byte cost depends heavily on the color type the file was written in. An RGB photo at 24 bits per pixel carries three full channels, an RGBA image carries four, and a palette-based image stores each pixel as an index into a short color table. Larger channel counts mean more data before compression ever begins, which is one reason the same visual content can weigh very different amounts depending on how it was exported.

Because the pixels are untouchable in lossless mode, the pass works around the edges of the file. Unused palette entries get dropped so indexed files never carry index values for colors that no longer exist. Non-essential metadata - text chunks, comments, author records and embedded preview data - is removed, trimming bytes with zero visual cost. Chunk ordering is normalized and redundant chunks are merged, which lets decoders read the file in fewer, cleaner operations.

There is a hard limit to how far this can go. DEFLATE has already squeezed the pixel stream once, so the re-encode is mostly re-packing the same luggage into a better suitcase. When a PNG shrinks by 5-15 percent and then stops, that is the format working exactly as designed, not the tool underachieving. The main structural lever that remains is interlacing: Adam7-interlaced files carry extra ordering data and routinely weigh more than their progressive counterparts.

• Metadata removal: text and comment chunks are stripped, which is pure size with no image cost.
• Palette cleanup: unused and duplicated entries are removed from indexed files.
• Chunk normalization: ordering is standardized and redundant structures are merged.
• Interlacing: where present, the ordering data adds weight that progressive storage avoids.

For anything with alpha, the practical field narrows quickly. JPG cannot hold transparency at all, GIF is limited to a binary transparent-or-not choice and a thin palette, and PNG and WebP are the two real contenders for smooth, semi-transparent edges. PNG wins on universal compatibility - every image viewer, editor and print pipeline reads it. WebP wins on size, and by a wide margin when the transparent content is photographic or gradient-heavy.

The choice is not either-or in a workflow sense. Keeping the WebP output costs a little of the absolute fidelity guarantee, but for web delivery the difference is invisible at normal quality values while the payload shrinks to a fraction. When the destination is a website or app with up-to-date browsers, the WebP export is usually the right call; when the file must survive an older ecosystem, the lossless PNG path earns its larger size.

A screenshot is mostly flat background with scattered text and UI, and it compresses remarkably well - the DEFLATE stream finds long runs of identical pixels. The gains are real but bounded, and the WebP path helps most when a screenshot holds gradients, blur effects or dark translucent overlays that defeat PNG's redundancy hunt.

A logo or flat icon is the format at its best: a handful of colors, clean edges and often an indexed palette, so the file is already small. Running such a file through a lossy encoder saves almost nothing, which is why the lossless pass is the right tool for most logo work. Photographic PNGs are the opposite extreme - raw pixels with no long runs - and they are the ones that benefit most from abandoning the lossless guarantee and taking the WebP route.

• Screenshots with text and flat UI: lossless PNG pass, keep it simple.
• Screenshots with gradients or translucent overlays: WebP export for real savings.
• Logos and flat icons: lossless PNG - the file is probably already near its floor.
• Photographic PNGs: WebP export, where the size gap to PNG is largest.
• Archival or print-bound files: lossless PNG, because fidelity and compatibility outweigh a few hundred kilobytes.

When the output is a lossy WebP, the quality slider becomes active and behaves like it does for a photograph in any codec: higher values keep more detail, lower values shrink the file. For transparent images there is an extra consideration, because the alpha edges are compressed too. At very low quality, the semi-transparent fringe where a cutout object meets its background can develop a thin halo or stair-step edge.

In practice the 75-85 band works as a starting point for photographic PNG converts, while transparent UI assets usually settle comfortably around 85-90 where the edges stay clean and the size is still far below the original PNG. If an edge artifact appears, the fix is to raise quality rather than lower it - the damage is in the encoding budget, not in the image itself.