How to compress images for the web
Most image weight is wasted long before the encoder runs. This is the order of operations that actually removes bytes — and the settings worth caring about.
Why image weight matters
On most sites, images are the single largest contributor to page weight — frequently more than all scripts, styles and fonts combined. That has two consequences. First, visitors on mobile data wait longer and pay for the privilege. Second, image weight maps directly onto Largest Contentful Paint, the Core Web Vital most often blamed for a poor performance score, because the largest element on a page is usually a hero image.
The good news: image weight is also the easiest thing to fix. Nothing here requires a build-pipeline overhaul.
Work in order of impact
Compression tools tempt you to reach for the quality slider first. That is the smallest of the three levers. The order should be:
- Resize — the largest win by a wide margin.
- Choose the format — a large, one-time win.
- Set the quality — fine-tuning, with real but bounded returns.
1. Resize first
A 4000-pixel-wide photograph displayed in an 800-pixel-wide slot is carrying roughly 25 times more pixels than it can show. No codec can make up that gap. Serving an oversized image and then compressing it aggressively is the classic mistake: you pay twice, and the visible result is worse than if you had simply resized properly.
Resize to the actual display size, doubled for high-density screens if the image matters. As a rule of thumb, a full-width hero image rarely needs to exceed about 2000 pixels wide, and in-page content images rarely need more than 1200.
2. Choose the format
Photographs should go to AVIF or WebP. Graphics with sharp edges, text or transparency should stay PNG or lossless WebP. The format guide covers the trade-offs in detail; the short version is that format choice is a per-image-kind decision, not a global one.
3. Set the quality
For lossy formats, quality is a 0–100 dial that trades fidelity against size. It is not linear: dropping from 90 to 80 often cuts a third of the file for no perceptible difference, while dropping from 50 to 40 mostly produces visible artefacts.
Sensible starting points:
| Content | Rough target | Notes |
|---|---|---|
| Photographs for web | JPEG/WebP quality ~75 | The usual sweet spot; AVIF reaches comparable quality lower still |
| Thumbnails, avatars | quality 60–70 | Small display size hides more than you would expect |
| Screenshots, UI, text | Lossless (PNG / lossless WebP) | Any lossy compression smears 1-pixel edges and glyphs |
| Archival / print | Quality 90+, or original | Keep the original; this is not a web-delivery scenario |
Judge at display size, not zoomed in. Compare the compressed and original images at the size they will actually appear. Differences that are glaring at 400% zoom are usually invisible in context.
A batch workflow that scales
- Collect everything into one folder — screenshots, photos, exports.
- Split into two groups: photographic and graphical. They take different formats and different settings.
- Resize each group to its delivery dimensions.
- Compress the photographic group to AVIF and WebP; compress the graphical group losslessly.
- Compare each result against its original. Anything that got larger gets discarded — that is a signal, not a failure.
- Keep the originals. Compressed output is a build artefact; your originals are the archive.
tinyimg handles steps 4 and 5 for up to 30 files at a time, and can emit several formats from one pass so you can compare sizes directly. Batch processing in the browser also means a folder of client or personal photos never leaves your machine — worth having if upload policies are a consideration.
Mistakes that quietly waste the most bytes
- Shipping one huge image to every device. A single 2000-pixel JPEG is not a responsive strategy. Use
srcsetso phones fetch a smaller variant. - Re-saving JPEGs repeatedly. Each lossy generation compounds the damage. Always re-encode from the original.
- Using PNG for photographs. Frequently 5–10× larger than the JPEG equivalent for no visible benefit.
- Chasing "smallest possible" past the point of usefulness. A 40% saving is excellent; 45% with visible banding in the sky is not.
- Forgetting lazy loading. Below-the-fold images should not block first paint. Lazy loading is a one-attribute change with a large effect.
- Never re-measuring. Set a budget, then check it — otherwise it drifts upward one asset at a time.
Knowing when you are done
Pick a page budget and hold it. A reasonable target for a content page is to keep the total image payload under roughly a megabyte, with the hero image doing the most work. If a page blows past that, the usual culprits are an unresized hero, a photograph stored as PNG, or several decorative images that could be SVG or CSS instead.
The exercise is unglamorous but short: resize, choose a format, set a sane quality, verify at display size, and keep the originals. That sequence removes the overwhelming majority of avoidable image weight on almost any site.