PNG Compressor — Lossless & Smart Palette Compression With Before/After Preview

What a PNG compressor actually does

PNG is a lossless format. Its compression is DEFLATE, the same algorithm a ZIP file uses, and DEFLATE never throws a pixel away. So when a tool claims to make a PNG 70% smaller, it is doing one of two very different things, and the difference matters enormously:

1. Re-encoding the same pixels more efficiently. This is genuinely lossless. A PNG encoder chooses between five row filters, decides how to split the DEFLATE stream, and writes the result. The pixels come out identical. The catch is that most PNGs on the web have already been through an encoder — an image editor, a screenshot tool, an optimisation plugin — so there is often little left to win. Truly lossless re-encoding of an already-optimised PNG typically saves 0–15%, and frequently saves nothing at all.
2. Reducing the number of colours. A truecolour PNG can hold up to 16.7 million colours. Most graphics do not need that many. Converting to an indexed palette of 256, 128, 64 or 32 colours and storing one index per pixel instead of four bytes per pixel is where the dramatic 50–80% savings come from — and it permanently changes pixels. The file is still a valid PNG, still lossless from that point on, but it is no longer identical to the original.

Almost every "PNG compressor" on the web blurs those two things together behind a single slider. This tool keeps them separate and labels each one honestly, because the right choice depends entirely on what the image is.

A brief history of PNG (and why it replaced GIF)

PNG stands for Portable Network Graphics. It was created in 1995 as a free, open alternative to the GIF format, which was previously the standard for displaying graphics with transparency on the web.

The primary driver for PNG's creation was a patent dispute. The company Unisys held a patent on the LZW compression algorithm used by GIFs, and began charging royalties to software developers who created GIF-exporting tools. The web community needed a format that was legally unencumbered, supported more than 256 colours, and handled transparency better.

PNG solved all three problems. It uses the DEFLATE compression algorithm (which is public domain), it supports 24-bit truecolour (millions of colours), and it introduced the 8-bit alpha channel, allowing for smooth, semi-transparent edges rather than the harsh, jagged edges of GIFs.

Today, PNG remains the undisputed king for UI assets, logos, screenshots, and any graphic that requires crisp lines or transparency. However, because it is lossless, it is terrible for photographs — which is why formats like JPEG and WebP exist.

Web Image Formats Explained: When to Use PNG, JPG, WebP, and AVIF

Choosing the wrong file format is usually a bigger mistake than choosing the wrong compression level. Here is how the major web image formats compare:

If you are compressing a photograph that is currently a PNG, converting it to WebP or JPG will yield far more savings than trying to reduce its colour palette. If you are compressing a crisp UI screenshot, stick to PNG or lossless WebP to keep the text sharp.

The difference between lossy and lossless image compression

To understand how compression works, you have to understand the difference between lossless and lossy algorithms.

Lossless compression (used by PNG) works like a ZIP file. It finds patterns in the data and packs them more efficiently. If you have a row of 500 pure white pixels, a lossless encoder doesn't store "white, white, white..." 500 times. It stores a single command that means "500 white pixels". When the image is opened, the computer reconstructs the exact original. The file is smaller, but every single pixel is identical to the source.

Lossy compression (used by JPG) throws data away. It looks at the image and decides what the human eye is unlikely to notice. It might merge subtle variations in colour, or blur fine details in high-frequency areas (like the texture of grass). This allows it to achieve massive savings—a 5 MB photo can become a 150 KB JPG with almost no visible change. However, the original data is gone forever, and re-saving a JPG repeatedly will cause visible artefacts to build up.

This tool allows you to use both. The "Lossless" preset utilises a lossless algorithm on the PNG. The palette levels (256, 128, etc.) use a technique called "quantisation" which is a form of lossy compression specific to indexed colour. The JPG and WebP exports use standard lossy algorithms.

How to use this PNG compressor

1. Add a file. Drop it on the upload area, click to open the file browser, or press Ctrl/⌘ + V to paste an image straight from the clipboard. Three quick-preset buttons let you try a synthetic screenshot, a logo or a photo without hunting for a file. Multiple files are accepted; they are processed one at a time so memory use stays predictable.
2. Read the analysis. Before you choose anything, the panel reports the image's dimensions, bit depth, colour type, the exact number of unique colours and whether any pixel is less than fully opaque. Those two numbers — unique colours and transparency — are what actually determine how much a PNG can shrink.
3. Pick a level. The preset buttons each run a real encode and display the measured output size and percentage saved. Nothing is estimated. Lossless runs automatically as your baseline; the palette levels fill in as you click them.
4. Hit a target size. If you need the file under a specific weight, enter it in the target field and press Find. The tool will iterate through PNG palettes, or use lossy binary search for JPG/WebP, to find the highest quality that fits exactly under your limit.
5. Compare. Drag the divider across the before/after view to inspect the result on a transparency checkerboard. Use the 1:1 zoom toggle to see the image at native pixel size, and the Difference toggle to highlight every pixel that changed.
6. Download. Save the compressed PNG, or use the dedicated buttons to download as JPG or WebP. You can also batch download everything by selecting a format next to the Download All button.

Batch compressing PNG, JPG & WebP files

Real-world image optimisation is rarely a one-file job. If you are preparing a folder of product photos for a storefront, compressing a week's worth of UI mockups, or trying to get an entire blog post under a payload budget, doing them one at a time is tedious. This tool handles multiple files in a single batch.

Drop your files all at once and the tool processes them sequentially. You will get a separate analysis, preset grid, and preview for every image. This is critical: a screenshot might compress brilliantly at 256 colours, while a photograph sitting in the same batch will need a much smaller palette or a format change. The tool applies the correct logic per file rather than forcing one setting across the whole set.

When you are ready to save them, use the Download all button. Next to it sits a format selector. You can choose to export the entire batch as:

• Optimised PNGs: Keeps transparency, preserves every pixel if you used Lossless, and applies the exact palette size you selected on each file.
• Standard JPGs: The smallest option for photographs, though it flattens transparency onto a white background.
• Modern WebPs: The best of both worlds—keeps transparency, but is typically 25–35% smaller than an equivalent PNG.

The tool generates these versions on the fly. If you batch download as WebP, it does not just rename a PNG; it re-encodes the entire batch using the browser's native WebP encoder, which gives you real, modern format savings without a server.

Hitting an exact file size with Target Size mode

Plenty of real-world tasks come with a hard byte limit — a job application that caps an image at 100 KB, an email attachment ceiling, a CMS upload limit, or a specific marketplace requirement. Because a PNG compressor works by choosing a palette size, it cannot hit an arbitrary number exactly. But it can find the highest-quality level that fits under your target, which is what you actually want.

Every result card has a target size field. Enter a number in kilobytes and press Find. What happens next depends on the format you selected:

• If you select PNG: The tool tests each palette level from largest (256 colours) to smallest, measuring the real byte output at each step, and reports the first one that lands under your number.
• If you select JPG or WebP: The tool runs a binary search algorithm on the quality slider. It starts at 50%, checks the file size, and quickly hones in on the highest quality setting that still fits under your target.

If even the most aggressive compression cannot reach the target (for example, a 4K photo that needs to be under 50 KB as a lossless PNG), the tool says so plainly instead of silently converting the image behind your back.

The single number that predicts your saving

Unique colour count is the most useful diagnostic in PNG compression, and almost no tool shows it. The reasoning is straightforward: an indexed PNG can store at most 256 colours. If your image already has fewer than 256 unique colours, palette reduction cannot help it at all — it is already at the format's limit and any further saving has to come from better encoding. If it has 300 colours, dropping to 256 is nearly free visually and can still cut the file substantially. If it has 400,000 colours, you are looking at a photograph and no palette size will preserve it.

💡 The tool samples very large images rather than reading every pixel, and says so when it does. On a 12-megapixel PNG it inspects roughly 1.5 million pixels, which is statistically more than enough to establish the colour count without making you wait.

Lossless versus palette reduction, side by side

⚠ Terminology trap. Tools that reduce the palette still describe their output as a "lossless PNG", and technically they are right — the file is a valid lossless PNG after the conversion. But a pixel comparison against your original will show differences. If a workflow requires bit-identical output, use Lossless mode only, and accept the smaller saving.

Understanding alpha channels: How PNG transparency really works

Transparency is one of PNG's superpowers, and the reason it remains so popular for web design. Under the hood, transparency is stored in the "alpha channel".

Every pixel in a standard image has three colour values: Red, Green, and Blue (RGB). A PNG with transparency has a fourth value: Alpha. This alpha value dictates how opaque the pixel is, ranging from 0 (fully transparent) to 255 (fully opaque).

Older formats like GIF only supported 1-bit transparency. A pixel was either 100% visible or 100% invisible. This resulted in jagged, pixelated edges around curves and text. PNG introduced 8-bit transparency, which means there are 256 levels of opacity. This allows for soft, semi-transparent drop shadows, feathered edges, and glass effects that blend beautifully into whatever is behind them.

When you use the palette reduction modes in this tool, the encoder has to reduce the number of alpha values along with the colours. If you compress an image with a soft shadow down to 32 colours, that shadow might turn into a harsh, banded gradient. If you need to preserve smooth transparency, keep the palette level at 256 or higher, or convert to WebP.

Real-world scenarios: When you absolutely need to compress a PNG

PNG compression is a critical step in many professional workflows:

• E-commerce storefronts: Product photos are often placed on transparent backgrounds (so they can sit on any coloured page). A 3 MB PNG product image will severely slow down a product page. Compressing it to 256 colours and 200 KB makes the store load instantly.
• Web and App Design: UI assets like buttons, icons, and backgrounds are usually exported as PNGs. A single app screen might require 30 small PNGs. Compressing them collectively saves megabytes in the app bundle.
• Email Newsletters: Email clients often block remote images by default, and heavy images cause newsletters to be clipped by Gmail. Compressing a header graphic ensures the entire message is delivered.
• Game Development: 2D sprites, textures, and UI elements rely heavily on transparency. Tools like Unity and Godot can load smaller textures into memory much faster, improving frame rates.
• Document Archiving: When converting documents to digital archives, scanning them as PNG ensures text is crisp, but uncompressed scans can be 20 MB per page. Palette reduction brings that down to a manageable 2 MB without sacrificing legibility.

Compressing PNGs with transparency

Transparency is where PNG compression gets hard, and where most tools quietly deliver the worst results. The reason is structural: a PNG with an alpha channel stores four values per pixel instead of three. A soft drop shadow, a feathered edge or a glass effect contains hundreds of distinct alpha values, and palette reduction has to collapse those into a much smaller set.

The measured reality is sobering. In a 1,000-image benchmark, the worst case for browser-based compression was PNGs with alpha transparency, which achieved only about 15% reduction without visible quality loss. Images with large flat transparent areas — a logo on a transparent background, an icon with hard edges — do far better. Images with soft, continuous transparency do far worse.

This tool reports whether any pixel is non-opaque before you compress, so you know which situation you are in. If the analysis says "fully opaque", palette levels will behave well. If it says "has transparency", check the before/after preview carefully at 1:1 before committing.

When PNG is the wrong format entirely

The most important optimisation decision is not the compression level — it is the format. Compressing a photograph as a PNG, even aggressively, is polishing the wrong object.

This is why the tool measures WebP and JPG alongside every PNG level. If the WebP or JPG column is dramatically smaller than every PNG column, that is the tool telling you the honest answer: change format rather than compress harder.

Converting PNG to JPG and WebP

PNG is excellent for sharp edges, flat colours, and crisp text. It is terrible for photographs. If you are dealing with a photograph that has been saved as a PNG, no amount of palette reduction is going to make it look good—you will just get a smaller, blocky, artefact-heavy image.

The solution is to change formats. This tool handles that directly in the browser:

• Converting to JPG: JPG is a lossy format that is incredibly efficient at storing photographs. When you click the "Download JPG" button, the browser compresses the image using the JPEG algorithm. Because JPG does not support transparency, any transparent pixels are flattened against a solid white background.
• Converting to WebP: WebP is Google's modern image format. It supports both lossy and lossless compression and—crucially—it supports transparency. In most cases, converting a PNG to WebP will yield a file that is 25–35% smaller than the original PNG while maintaining identical visual fidelity.

The comparison chart at the bottom of every result card shows you exactly how big the file would be if you exported it as a JPG or WebP. If you see that a 2 MB PNG would be 150 KB as a WebP, you have found your answer.

Why PNG weight matters for page speed and search

On roughly 70% of pages, the Largest Contentful Paint element — the single biggest Core Web Vital — is an image. A heavy PNG sitting in the hero position delays LCP directly, and LCP is part of the page-experience signal set. That is the mechanical link between image weight and search performance; it is real, and it is measurable in PageSpeed Insights.

But compression level is rarely the biggest lever. Order of impact, largest first:

1. Format. Serving a photograph as AVIF, WebP or JPG instead of PNG typically saves 60–90%. No palette setting comes close.
2. Dimensions. Shipping a 3000-pixel-wide image into a 600-pixel slot wastes about 25× the bytes. Resize before compressing — there is a dedicated image resizer and an image downscaler on this site for exactly that.
3. Compression. What this tool does — meaningful, but third in line.
4. Delivery. srcset, lazy loading, and a CDN cache. Nothing to do with the file itself.

💡 A practical target: hero and LCP images often aim for 60–150 KB at 1× pixel density and under about 200 KB as a hard ceiling. Card and thumbnail images should be far smaller. If your PNG is 2 MB and 4000 pixels wide, resizing will beat compressing by an order of magnitude.

Common mistakes when compressing PNGs

• Compressing an already-optimised file and assuming something broke. If a PNG has been through an image editor's export pipeline, OxiPNG, or a CDN optimiser, there may genuinely be nothing left. A tool that reports "no gain" is being honest; a tool that reports 40% on every file is not.
• Palette-reducing a photograph. Dropping a 400,000-colour photo to 256 colours produces visible posterisation — flat patches where there should be gradients. Photographs belong in WebP, AVIF or JPG.
• Palette-reducing a soft shadow. A product photo with a feathered drop shadow is the classic casualty. The shadow bands into visible rings while the rest of the image looks perfect, so it is easy to miss in a thumbnail preview. Always check at 1:1.
• Trusting a thumbnail preview. Banding and text artefacts are invisible when the image is scaled down to fit a panel. Use the 1:1 zoom toggle and the Difference view.
• Compressing before resizing. If the image needs to be 1200 pixels wide, resize first and compress second. Compressing a 4000-pixel image and then letting CSS shrink it wastes almost all of the saving.
• Re-saving a lossy-compressed source as PNG. Converting a JPG to PNG does not restore detail — it just stores the JPG artefacts losslessly, at a much larger size. If the source is JPG, keep it JPG or move forward to WebP/AVIF.
• Assuming smaller always means better. For a file that will be printed, edited further, or archived, keeping full colour depth is worth the bytes. Compression is a delivery decision, not an archival one.
• Overwriting the only copy. Palette reduction is not reversible. Keep the original — the tool never touches your source file, but your file manager might.

Privacy — and how to verify it yourself

The file is read with the browser's FileReader API, decoded in JavaScript, re-encoded in JavaScript and handed back as a Blob for download. There is no upload endpoint in the code, no account, and no request that carries image data. The only network request on the page is the one that loads the encoder library itself.

You do not have to take that on trust. Open your browser's developer tools, switch to the Network tab, and compress a file — you will see no request containing your image. Or load the page once, disconnect from the internet, and compress again: it still works. That test is available to anyone and is the reason this tool can honestly claim local processing rather than merely asserting it.

That matters more than it might seem. In a 2026 benchmark of ten popular online compressors, only two processed images locally in the browser — the other eight uploaded every file to a remote server. For client work, unreleased product shots, personal photos or anything under NDA, that distinction is the whole decision.

Limitations

• 8 bits per channel. The encoder works in RGBA8. A 16-bit PNG is reduced to 8-bit during compression. Invisible on screen, destructive for print, HDR or scientific work — the analysis panel flags 16-bit files so you can decide.
• First frame only for APNG. Animated PNGs are detected and warned about, but only the first frame is compressed. The tool will not silently flatten your animation.
• No interlaced output. Interlaced PNGs are decoded correctly and re-encoded as non-interlaced, which is almost always smaller anyway.
• Ancillary metadata is dropped. Re-encoding rebuilds the file from pixel data, so text chunks, physical-dimension hints, embedded colour profiles and timestamps are not carried over. For web delivery this is desirable; for archival or colour-managed workflows it is not.
• Memory bound. Decoding to raw RGBA needs four bytes per pixel. A 4000 × 3000 image occupies about 48 MB while processing. Very large images may be slow or fail on low-memory mobile devices — which is why files are handled one at a time rather than all at once.
• No arbitrary target-size mode for lossless. A lossless optimiser cannot promise a specific byte count, because it never discards detail. Target-size mode picks the highest-quality palette that fits, but if the target is unreachable, the tool says so rather than falling back to a lossy format behind your back.
• Savings are not guaranteed. This is a feature of honesty rather than a defect. Some PNGs simply cannot get smaller without changing what they look like.

Frequently asked questions