A screenshot weighs 4 MB. An exported icon hits 2 MB. A chart from a design tool arrives at 8 MB. PNG files seem to inflate out of nowhere — and unlike JPG, "just lower the quality" isn't an option, because PNG has no quality dial. Here are the four real reasons PNGs get huge, and the fix for each.
Quickest fix for sharing: convert the PNG to WebP in the compressor — transparency preserved, typically 80%+ smaller.
Shrink my PNGCause 1: Too many pixels
PNG stores a fixed number of bytes per pixel region, so file size scales directly with dimensions. A screenshot of a 4K monitor (3840×2160) contains four times the pixels of a 1080p one and roughly four times the bytes. Retina displays make this worse: every "normal-looking" screenshot is secretly double resolution.
Fix: resize to the size you'll actually display. Sharing a screenshot in chat? 1280 px wide is plenty. This one change routinely cuts PNGs by 60–75%.
Cause 2: Photographic content
PNG's lossless compression (DEFLATE) was designed for data that repeats predictably — flat colors, runs of identical pixels. Photos are the opposite: near-random detail everywhere. The compressor finds almost nothing to exploit, so a photo saved as PNG can be 5–10× the size of the same photo as JPG or WebP.
Fix: photos never belong in PNG unless you need bit-perfect archival. Convert to WebP (keeps transparency if there is any) or JPG. See our format comparison for the full picture.
Cause 3: Full 24/32-bit color on flat graphics
A logo with 12 colors stored as 24-bit RGBA dedicates 4 bytes per pixel regardless. Palette-based PNG-8 uses 1 byte per pixel with an indexed color table — for flat graphics this is visually identical and 60–80% smaller.
Fix: export or convert flat-color graphics to PNG-8 (palette mode), or better, SVG if the graphic is shape-based.
Cause 4: Suboptimal encoding and dead metadata
Not all PNG encoders are equal. A design tool exporting PNG quickly may skip advanced compression settings, leaving 10–20% on the table. Embedded color profiles, EXIF chunks, and editor metadata add further weight — occasionally kilobytes, sometimes hundreds of them on small images.
Fix: re-encode with an optimizer (oxipng, zopfli) — mathematically lossless, still meaningfully smaller.
What actually works, in order of impact
| Lever | Typical saving | Lossless? |
|---|---|---|
| Convert photo-PNG → WebP/JPG | 70–90% | Visually lossless |
| Resize to display size | 50–75% | Depends on display size |
| 24-bit → 8-bit palette (flat graphics) | 60–80% | Effectively yes |
| Optimizer re-encode + metadata strip | 10–25% | Bit-perfect |
When you must keep it a PNG
Some pipelines require .png exactly — texture workflows, some documentation systems, print handoff. In that case combine the lossless levers: correct dimensions, palette mode where possible, optimized encoding. If the file still must shrink dramatically below what lossless allows, something in the requirement has to give.
For everything else, the practical move is one pass through the compressor: PNG in, WebP out, target size guaranteed, transparency intact.