Initializing... drag & drop files here
Supports: PNG
PNG uses lossless DEFLATE compression, which is great for crisp logos and transparent overlays but terrible for file size — a 1920x1080 screenshot can easily land at 3-5 MB, and a hero image at 4K can exceed 15 MB. Compression either keeps every pixel (lossless re-encoding via better DEFLATE passes like zopfli/optipng, typically 10-30% savings) or trades a few imperceptible colors for huge wins (lossy palette quantization, typically 60-80% savings via the same approach pngquant and TinyPNG use).
git clone; compressed PNGs keep transparency for dark/light theme overlays.| Variant | Bits/pixel | Colors | Transparency | Typical use | File size on 1080p flat graphic |
|---|---|---|---|---|---|
| PNG-8 | 8 (indexed) | 256 max | 1-bit (on/off) or indexed alpha | Icons, logos, UI sprites | Smallest — baseline |
| PNG-24 | 24 (truecolor) | ~16.7 million | None | Photographs, gradients | ~2x PNG-8 |
| PNG-32 | 32 (truecolor + alpha) | ~16.7 million | Full 8-bit alpha channel | Photos with soft transparency, hero shots | ~2.5-3x PNG-8 |
The PNG specification itself calls these "color types"; the "PNG-8/24/32" labels come from Adobe Photoshop's Save for Web dialog. Reducing colors from 24-bit truecolor down to an indexed 8-bit palette is the single biggest lever for shrinking a PNG.
| Format | Lossless savings vs PNG | Lossy savings vs PNG | Alpha | Browser support |
|---|---|---|---|---|
| PNG (baseline) | — | — | Full 8-bit | Universal |
| WebP | 23-42% smaller lossless (varies) | 25-34% smaller than equivalent JPEG | Full 8-bit | Chrome, Firefox, Edge, Safari 16+ (~96%) |
| AVIF | Up to ~50% smaller | Often 50%+ smaller than WebP | Full | Chrome 85+, Firefox 93+, Safari 16.4+ |
If you control the audience (web product, modern browsers), PNG to WebP usually wins on file size with no visible quality loss. PNG stays the right choice when you need universal compatibility, lossless guarantees, or transparency in tools that don't yet support AVIF.
| Method | Typical savings | Quality impact | Best for |
|---|---|---|---|
| Lossless re-encoding (zopfli/optipng style) | 10-30% | None — pixel identical | Logos, UI assets, line art, anything you'll edit again |
| Palette quantization (pngquant/TinyPNG style) | 60-80% | Minor color banding on gradients, usually invisible | Web hero images, screenshots, product photos with transparency |
| Convert to JPEG (drop alpha) | 80-95% | Visible artifacts at low quality | Photos with no transparency — use PNG to JPG |
For lossless compression expect 10-30% off the original — DEFLATE was already applied at save time, so the gains come from a smarter second pass. For lossy palette quantization (the technique pngquant and TinyPNG use) expect 60-80% savings on truecolor PNGs converted to 256-color indexed PNGs; banding only shows up in smooth gradients and is usually invisible at typical web zoom levels.
Yes. Both lossless re-encoding and palette quantization keep the alpha channel intact. PNG-8 stores 1-bit or indexed alpha (each palette entry has an alpha value), and PNG-24/32 keep full 8-bit alpha. The output stays PNG, so anything that consumed the original (CSS backgrounds, app icons, Photoshop layers) keeps working without code changes.
Lossless mode can only do so much with a 4K screenshot full of UI gradients and antialiased text. Drop "Image Quality (%)" toward 70-80 or enable Color Reduction + Dither to switch from 24-bit truecolor to an indexed palette — that single change typically saves 60-70%. If the screenshot doesn't need transparency, converting to JPEG cuts another 50-80% on top.
PNG-8 (8-bit indexed, up to 256 colors) is right for logos, icons, line art, screenshots of flat UI, and most charts. PNG-24 (24-bit truecolor, ~16.7M colors) is for photographs, gradients, and complex artwork. PNG-32 is PNG-24 plus an 8-bit alpha channel. The same image saved as PNG-24 is typically about twice the size of PNG-8 because fewer unique colors compress better under DEFLATE.
No — PNG is a raster format, so the file's pixel dimensions stay the same after compression. What changes is how those pixels are encoded (palette size, DEFLATE level). A 2x or 3x asset rendered crisp on a retina display before compression stays crisp after.
Large hero images and scans (50-200 MB) typically compress in a few seconds. Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after one hour — there's no per-file cap and no lingering storage.
The lossy mode here uses the same approach — palette quantization with dithering — that pngquant pioneered and TinyPNG popularized. Expect similar 60-80% savings on truecolor PNGs. TinyPNG's free tier caps you at 20 images per session and 5 MB per file; this tool has no per-image cap and no sign-up.
Often yes. If your source is 4000x3000 but you're using it as a 1200px-wide blog header, resizing the PNG first removes pixels that compression can't help with. Combine resize + lossy quantization and a 12 MB photo PNG can drop below 300 KB while still looking sharp.
PNG doesn't carry EXIF the way JPEG does, but it can hold tEXt/iTXt chunks (timestamps, software tags). Most compressors strip these by default to save bytes — if you need to preserve metadata for forensics or DAM workflows, keep an uncompressed original alongside the compressed asset.