Compress PNG images without losing quality

Why screenshots stay small and photos stay huge

Whether one PNG is 40 KB and another is 8 MB comes down to how predictable the pixels are. PNG compression thrives on repetition and flat color. A screenshot of a settings panel is mostly large blocks of the same gray, white text on solid backgrounds, and sharp edges between regions.

After filtering, most of those rows turn into long runs that DEFLATE crushes down to almost nothing. The same logic applies to logos, icons, line diagrams, and charts: limited colors, big flat areas, clean edges.

A photograph is the opposite. Every patch of sky has subtle noise, every blade of grass differs from its neighbor, and no two adjacent pixels are likely to match. The filter cannot predict much, so the differences it stores stay large and varied, and DEFLATE finds little repetition to exploit.

The result is a file that holds nearly the full information of the image with little gained. This is not a flaw in the tool or the encoder. It is the format doing what it promises: keeping every noisy pixel intact.

A quick test tells you which camp your image is in. If you can describe the picture as shapes and regions (a button, a header, a logo on a transparent background), PNG will treat it kindly. If you describe it as texture and continuous tone (a face, a landscape, a product shot), PNG will store it faithfully and largely, and a lossy format will serve you far better, so it is worth learning to convert it to JPG when the content is photographic.

Indexed color: the biggest lever you control

PNG comes in two broad flavors. Truecolor PNG (often called PNG-24 or PNG-32 when it carries an alpha channel) stores a full red, green, and blue value for every pixel, plus transparency. Indexed PNG (PNG-8) instead stores a small palette of up to 256 colors and then records one short index per pixel pointing into that palette. For the right image, the difference in size is enormous.

Consider a flat logo that uses six colors: two brand shades, black, white, and a couple of tints. As truecolor it spends three or four bytes per pixel even though only six distinct values ever appear. As an indexed image it stores those six colors once, then a single small index per pixel.

The visual result is identical because no color was lost, yet the file can shrink by half or more. This is the closest PNG gets to a free lunch: for graphics with few colors, a palette removes waste without removing any pixel data.

The catch is that indexed mode caps you at 256 colors. Force a photo or a rich gradient into a palette and you have to either drop colors (which is no longer lossless) or dither, which adds visible speckling. So the palette trick is the right move for flat graphics, brand assets, and simple illustrations, and the wrong move for anything with smooth tonal range. When you prepare files in a design tool, exporting genuinely flat artwork as indexed PNG often beats anything an after the fact compressor can do, because the savings come from the color model itself.

The alpha channel and how transparency survives

Transparency is the feature that keeps people loyal to PNG. The alpha channel stores, for each pixel, how opaque it is, from fully solid to fully see through, with every level in between. That is what lets a logo sit on any background, a UI sprite blend over a photo, or a product cutout drop onto a colored card without an ugly rectangle around it. JPEG has no alpha channel at all, which is the single biggest reason designers reach for PNG even when file size suffers.

Because PNG compression is lossless, the alpha channel survives untouched. A semi transparent drop shadow keeps its exact gradient of opacity, and anti aliased edges that fade from solid to transparent stay smooth. Running a transparent PNG through this tool does not flatten, fringe, or matte those edges. The output carries the same alpha values as the input.

This matters when you compare output formats on this page. Keep PNG and transparency is preserved exactly. Switch the output to WebP and transparency still carries over, because WebP supports an alpha channel too.

The one conversion that changes the picture is PNG to JPEG: since JPEG cannot store transparency, every transparent pixel gets filled with white. That is sometimes what you want for a final flattened export, but it is a real change, so the tool is explicit about it rather than silently discarding your alpha.

When PNG is right, and when to switch

PNG is the right choice whenever exactness or transparency matters. App Store and Play Store screenshots need crisp readable text and often have strict format rules, so PNG keeps every character legible. Documentation screenshots in Notion, Confluence, GitHub wikis, and internal handbooks read better as sharp PNG than as a slightly smeared lossy image.

Design handoff files belong in PNG too, since a developer needs to inspect exact colors and clean transparent edges. Logos, favicons, and UI sprites with hard edges all stay clean in PNG and would pick up halos or blur in a lossy format.

The signal to switch is photographic content. If your PNG is a photo, a rendered 3D scene, or anything with continuous tone and no transparency, you are storing megabytes to preserve noise that the eye cannot distinguish from a much smaller lossy version. For those, JPEG is the long standing choice for photos without transparency, and you can convert it to JPG in one step, filling any transparency with white, then compress a JPEG further if you need a smaller file. If you want a single modern format that covers both lossy photos and lossless graphics, you can convert to WebP instead.

There is also a middle case worth naming. Sometimes a PNG is mostly flat graphics but happens to be saved as truecolor with far more color depth than it uses. Those files respond well to honest lossless compression and palette reduction, and they stay PNG. The decision tree is simple: keep PNG when you need exact pixels or transparency, reduce the palette when the image is genuinely flat, and switch formats when the content is photographic.

PNG versus WebP lossless, and the practical numbers

WebP has a lossless mode that competes directly with PNG, and for most graphics it wins on size. Across typical icons, screenshots, and flat illustrations, WebP lossless lands roughly 25 to 34 percent smaller than the equivalent PNG while staying pixel for pixel identical.

It uses smarter prediction and a stronger entropy coder than DEFLATE, and it supports the same alpha channel, so transparency carries over intact. On this page, switching the output toggle to WebP is a single click, and the savings add up fast across a page full of images.

The tradeoff is compatibility, and it is smaller than it used to be. Every current browser decodes WebP, as the image file type reference shows, so for the modern web it is a safe default. The friction shows up at the edges: some older desktop software, a few email clients, and certain upload pipelines still expect PNG and will reject or mishandle WebP.

If a file is destined for a design tool, a printer, or a colleague on an unknown setup, PNG remains the universally understood choice. If it is going on a website you control, WebP usually deserves the slot.

A reasonable workflow is to keep masters as PNG for archival and editing, then export WebP for delivery where the platform accepts it. You lose nothing by storing the lossless PNG, and you gain real bandwidth on every page view by shipping the smaller WebP. Whichever you choose, the work happens locally in your browser: batches of up to 100 files, each up to 50 MB, processed without a single byte leaving your device, free with no signup, account, watermark, or ads.