A single unedited photo from a modern phone can be 5MB. Put ten of those on a page and you have built something most visitors will abandon before it finishes loading. The good news is that most of that weight is unnecessary, and removing it costs almost nothing in visible quality.
An image file stores a value for every pixel. A 12-megapixel photo contains twelve million of them, and before compression each one needs three colour channels. That is roughly 36MB of raw data before any encoding happens.
Compression is what brings that down to something manageable, and it works in two fundamentally different ways — which is where most of the confusion comes from.
| Type | What it does | Typical saving | Use for |
|---|---|---|---|
| Lossless | Rewrites data more efficiently; every pixel is recoverable exactly | 5-20% | Logos, screenshots with text, source files |
| Lossy | Discards detail the eye is unlikely to notice | 50-80% | Photographs, web images |
The word "lossy" sounds alarming, but applied sensibly the discarded information is genuinely imperceptible. A well-compressed JPEG at quality 80 is very hard to distinguish from the original at normal viewing size, while being a fraction of the size.
Lossless matters where precision is required. A screenshot containing text compressed with JPEG produces muddy, fringing characters; PNG keeps them crisp. That is why the rule of thumb exists at all.
| Format | Best for | Transparency | Notes |
|---|---|---|---|
| JPEG | Photographs | No | Smallest for photos; no alpha channel |
| PNG | Screenshots, logos, text | Yes | Lossless; much larger than JPEG for photos |
| WebP | Almost everything on the web | Yes | Typically 25-35% smaller than PNG or JPEG at equal quality |
| SVG | Icons, simple graphics | Yes | Vector — scales infinitely, tiny file |
| GIF | Simple animation | Yes | Limited to 256 colours; poor for photos |
If you are publishing to the web and not constrained by legacy support, WebP is usually the right answer. It supports both lossy and lossless modes plus transparency, and it is supported by every current browser.
Compress with TinyPNG → Or use PicCalc locally
The default choice for most developers. It reduces the colour palette rather than blurring pixels, typically saving 50–70% with no visible difference on screenshots and flat graphics. Free with a batch limit, and it preserves PNG transparency — which naive JPEG conversion destroys.
Worth choosing when images are confidential, because compression happens locally in your browser and nothing is uploaded. It also shows the size before and after, so you can see exactly what you saved.
Better when you also need a format change — for example converting a batch of PNGs to WebP, which is often a larger saving than compressing within the same format.
Typically 50-70% for photographs using lossy compression, and noticeably more if you also resize to the dimensions you actually display.
Not at sensible settings. It discards detail the eye generally cannot perceive. It is only a problem if you compress repeatedly or push quality very low.
For web publishing, usually yes. WebP is typically 25-35% smaller at equivalent quality and supports transparency, with support in all current browsers.
You probably used JPEG. Screenshots with text and flat UI need PNG or lossless WebP to stay crisp.
Yes — it is usually the single largest saving. Serving an image at the size it is displayed beats any compression setting.
Yes. PicCalc performs compression locally in your browser, so the file never leaves your device.