How to compress images for the web without losing quality
Updated 2026 · 8 min read
Images are usually the heaviest thing on a web page. On a typical content site, they account for 60–75% of total page weight, which means image compression is almost always the single highest-leverage optimisation available — far more than minifying CSS or deferring JavaScript.
The good news is that most sites are carrying image weight they simply do not need. Cutting it by 60–80% with no visible difference is routine, not heroic.
Lossy vs lossless: the only distinction that matters
Lossless compression rewrites the file more efficiently without discarding any information. The decoded image is pixel-identical to the original. Savings are modest — typically 5–20%.
Lossy compression deliberately discards detail that human vision is poor at detecting: fine colour gradations, high-frequency texture. Savings are dramatic — 70–90% — and at sensible settings the difference is genuinely invisible in normal viewing conditions.
For photographs on the web, lossy is the correct default. Reserve lossless for logos, screenshots, interface elements and anything with text or hard edges, where lossy artefacts show up immediately as smudging around letterforms.
Picking a format
| Format | Use it for | Transparency | Animation | Browser support |
|---|---|---|---|---|
| JPEG | Photographs, gradients, anything with millions of colours | No | No | Universal |
| PNG | Screenshots, logos, line art, transparency | Yes | No | Universal |
| WebP | Almost everything — replaces both of the above | Yes | Yes | All modern browsers |
| AVIF | Maximum compression where encoding time is not critical | Yes | Yes | Modern browsers |
| SVG | Icons, logos, simple illustrations | Yes | Yes | Universal |
If you only remember one thing: use WebP for photos, PNG for graphics, SVG for icons. WebP typically produces files 25–35% smaller than an equivalent-quality JPEG, and it supports transparency, so it replaces PNG as well.
The quality setting: where the sweet spot is
JPEG and WebP quality is usually expressed on a 0–100 scale. The relationship between that number and visible quality is not linear — most of the file-size reduction happens between 100 and 75, while most of the visible damage happens below 60.
- 90–100 — effectively no saving. Only use this for archival masters.
- 75–85 — the practical range for websites. Files shrink 50–70% and side-by-side comparison is needed to spot any difference.
- 60–75 — acceptable for thumbnails and background images nobody looks at closely.
- Below 50 — visible blocking, ringing around edges, and colour banding in skies and shadows.
Start at 80. If the page is still heavy, step down to 75, then 70. Below that, reduce dimensions instead — that is where the remaining savings are.
Dimensions beat quality
Halving an image's width and height quarters its pixel count. That is a far more powerful lever than any quality setting, and most sites are serving images far larger than anyone can see.
A photograph that is 4000 px wide contains four times the pixels of a 2000 px version, yet on a 1440 px laptop screen both are displayed at the same size. Unless your layout genuinely uses a full-bleed hero image, 1600–1920 px is more than enough for almost every web use case.
Worked example: a 4000 × 3000 photo exported from a camera might be 4.5 MB. Resized to 1600 px wide and saved as WebP at quality 80, the same image lands around 180 KB — a 96% reduction that nobody viewing the page will notice.
Realistic target file sizes
| Image role | Recommended max width | Recommended file size |
|---|---|---|
| Full-width hero image | 1920 px | 200–350 KB |
| In-article image | 1200–1600 px | 100–200 KB |
| Thumbnail / card | 400–600 px | 20–50 KB |
| Logo (SVG preferred) | Vector | Under 20 KB |
| Open Graph preview | 1200 × 630 | Under 300 KB |
As a page-level budget: keep the total transferred weight of a content page under roughly 1.5 MB. Pages that stay under that threshold load comfortably on mobile connections, and mobile is where the majority of your visitors are.
A five-minute workflow
- Resize first. Set the maximum width to the largest size your layout actually displays.
- Choose WebP for photographs, PNG for anything with text or transparency.
- Set quality to 80, then lower it only if the file is still too big.
- Check the result at 100% zoom — zoomed-out previews hide artefacts that readers will see.
- Compare before and after. If you cannot tell which is which, keep the smaller one.
You can do all five steps with the image compressor and image resizer on this site, entirely in your browser.
Mistakes to avoid
- Compressing an already-compressed image. Re-encoding a JPEG that came from social media adds artefacts without saving much. Always work from the original export.
- Using PNG for photographs. PNG is lossless; on a photo it can easily produce a file larger than the source.
- Ignoring the preview. Compression artefacts concentrate in flat areas — skies, skin, gradients. Look there, not at the busy parts of the image.
- Optimising once and never again. Make it part of your publishing checklist, not a cleanup project you do once a year.