You run a 200 KB PNG through a compressor and get 350 KB back. The tool is not broken. What matters is whether the compression method fits the content. Once that clicks, you control file size instead of guessing parameters.
Two kinds of compression
Lossy compression (JPEG, lossy WebP) discards high-frequency detail the eye barely notices and often cuts size to a tenth. Lossless compression (PNG, lossless WebP) changes no pixel at all, only re-packs the data, so the ratio depends on how many repeated patterns the image contains.
That leads to the key conclusion: lossless is excellent for flat colours, large areas of one tone and regular lines, and close to useless for photos — noisy, gradient-heavy, detail-dense images — where it can even grow the file because more index data has to be written.
Three typical "it got bigger" cases
1. Saving a photo as PNG. Every pixel differs slightly, so PNG finds nothing to reuse and stores it honestly. A 1920×1080 photo as PNG is often 3–5 MB; as JPEG at quality 80 it is roughly 300 KB.
2. Saving a screenshot or icon as JPEG. The reverse also fails: text edges and flat panels develop mosquito noise under lossy compression, so you raise quality to keep them legible — and the file ends up larger than the original PNG. Screenshots belong in PNG or lossless WebP.
3. Re-compressing an already compressed image. A JPEG downloaded from a chat app or a website is already lossy. Compressing again only stacks the damage: slightly smaller file, visibly worse image. Go back to the original source instead.
Choosing by content
- Photos, portraits, landscapes → JPEG (quality 75–85) or lossy WebP (25–35% smaller at equal quality)
- Screenshots, charts, UI captures with text → PNG or lossless WebP
- Icons, logos, simple illustrations → SVG (vector, sharp at any size)
- Transparent backgrounds → PNG or WebP (JPEG has no alpha channel)
- Animated images → prefer video formats or animated WebP; GIF is the least efficient option
Beyond the format
Maximum dimension usually beats the quality slider. Images shown in body text rarely need more than 800–1200 pixels wide; scaling a 4000-pixel original down to 1200 can cut size by an order of magnitude with no visible difference.
Quality setting: for JPEG, 75–85 is the sweet spot. Above that, size climbs fast while quality improves very little.
Metadata: camera files carry EXIF (location, device, timestamp) which costs bytes and can leak privacy. Strip it before publishing.
In one sentence
Lossy for photos, lossless for screenshots, shrink dimensions before touching quality. That single rule ends the "it got bigger" surprise.
One table to pick the format
Decide from the content type first, then the format. That is the only order that avoids repeated trial and error:
| Image content | Preferred format | Settings | Watch out |
|---|---|---|---|
| Photos, portraits, landscapes | Lossy WebP / JPEG | Quality 75–85 | No transparency |
| UI screenshots, images with text | PNG or lossless WebP | No quality setting | Never convert to JPEG |
| Icons, logos, simple illustrations | SVG | — | Vector, scales cleanly |
| Needs a transparent background | PNG / WebP | — | JPEG has no alpha channel |
| Short animations | Animated WebP / MP4 | — | GIF is the least efficient |
You do not memorise this table; you ask one question before compressing — "is this a photo or a screenshot?" Answer that correctly and there is little left to tune.
WebP versus AVIF
WebP is broadly supported across every mainstream browser, produces files 25–35% smaller than JPEG at matched quality, and handles transparency and animation. It is the safest default today.
AVIF compresses further — another 20–30% below WebP at the same quality — but two costs are real: encoding is dramatically slower (an order of magnitude in batch jobs), and decoding still is not universally available on older devices and browsers. For a public site, AVIF works best as a progressive enhancement served when supported, not as the only format.
The pragmatic combination: ship WebP for the main image and keep a JPEG fallback. You get the size benefit without blank images in the margins.
Three ways to handle a transparent background
- Keep it (PNG / WebP). Right for icons, stickers, and anything that sits on a background you do not control. The cost is size — with large semi-transparent areas such as soft shadows or gradient glows, PNG compression drops off sharply.
- Flatten onto a solid colour (JPEG). If the image will always sit on white or a known dark tone, fill the background with that colour and save as JPEG; the file can shrink to a third. The prerequisite is that the surrounding colour never changes.
- Convert to vector (SVG). Ideal for single-colour icons: a few kilobytes, infinitely sharp, recolourable with CSS. Complex gradients and textures do not vectorise well.
A common mistake: saving a logo with a transparent background as JPEG turns the empty area into a black or white block that becomes glaringly obvious on a dark page. That is a format limitation, not a software bug.
The order to batch-process in
The wrong order costs quality for nothing. Four steps, and the sequence is not negotiable:
- Crop first. Remove what you do not need. Cropping before scaling preserves more detail and costs less computation than the reverse.
- Then resize. Scale to 1.5–2× the final display size to cover high-density screens. This step affects file size more than any quality setting.
- Then compress. Choose the format and quality once and be done — do not compress repeatedly to "see how it looks", because each lossy pass can add another layer of damage.
- Finally strip metadata. Remove EXIF location, device model and timestamp. Smaller file, and no private data published by accident.
The common inversion — compress before resizing — throws detail away in a step where the damage cannot be recovered later.
Judging whether the result is still usable
Do not judge from the thumbnail. Put the before and after side by side at 100% and inspect three places:
- Text edges. Lossy compression fails here first, showing ringing or coloured noise around glyphs.
- Large gradients such as sky or a plain wall. Over-compression produces visible banding where the smooth ramp becomes stepped.
- Fine texture — hair, grass, fabric. This is where detail mushes together first.
If all three survive, the image will look fine at display size — which is how web images are almost always viewed anyway.