How to compress images for the web in 2026

Page weight matters. The bigger your images, the slower your site, the worse your Core Web Vitals score, and the more bandwidth your visitors spend (especially on mobile data). The good news: most images can shrink by 60–80% without anyone noticing.

Here's the playbook.

Pick the right format first

The biggest savings come from format choice, not from quality settings:

• WebP — the right default for almost every photographic image on the web in 2026. Smaller than JPEG at equivalent quality, supports transparency, and works in every browser anyone uses. If you have to pick one, pick this.
• JPEG — still the right call when you need universal compatibility outside of browsers (email clients, older CMSs, design tools that don't speak WebP). Slightly larger than WebP but mature and predictable.
• PNG — for screenshots, line art, and anything where pixel-perfect fidelity matters. Don't use it for photographs; the file will be 3–5× the size of an equivalent JPEG.
• AVIF — newer, often even smaller than WebP. Encoding is slow and not every tool supports it. Worth it for hero images on a high-traffic site, overkill for an internal product page.

If you're doing nothing else, converting your PNGs of photos to WebP will halve your image weight overnight. Try it on the image converter.

Choose a sensible quality

For lossy formats (JPEG, WebP, AVIF), quality settings between 70 and 85 hit the sweet spot for most photographs. Below 70 you'll start seeing artefacts in flat areas (skies, skin); above 85 you're paying for fidelity no one will notice. Compare side-by-side at 100% zoom — if you can't tell them apart, go with the smaller one.

A pragmatic default:

• Hero images on a marketing page: WebP, quality 85
• Product gallery photos: WebP, quality 80
• Thumbnails: WebP, quality 70
• Icons / line art: PNG (small enough already)

Resize before you compress

The single biggest waste in image weight is shipping a 4000×3000 image into a slot that displays it at 800×600. The browser has to download all those extra pixels just to throw them away.

Always resize to the actual display dimensions (or 2× for retina) before compressing. Our image resizer handles this in one click with aspect-ratio lock.

Don't strip the wrong things

Modern browsers use JPEG metadata for things like color profiles and EXIF orientation. Strip too aggressively and your portrait photo turns up sideways, or your colors look subtly off. Most automated optimizers handle this correctly, but if you're cropping with custom code, double-check that you're preserving the orientation tag.

Where to do the work

Three options, in order of how much they cost you:

1. At build time — Next.js, Astro, and most modern frameworks have an image pipeline that runs on build. Enable it, point it at your raw assets, and the framework generates optimized versions in multiple formats. This is the right answer for most sites.
2. In a CDN with image processing — Cloudflare Images, Imgix, Cloudinary. Pay-per-image. Good when you can't run a build (CMS-driven content) or need on-the-fly transforms.
3. In the browser before upload — useful for user-generated content. Compress the user's photo to a reasonable size before they hit "Submit." Saves their bandwidth and your storage. Our compressor uses browser-image-compression for exactly this.

For one-offs — preparing a batch of photos for a blog post, shrinking screenshots before sharing, processing the contents of an old archive — the browser-based compressor is the fastest path. No upload, no signup, no wait.

A quick checklist

Before publishing any image-heavy page:

• [ ] Are images in WebP (or AVIF) where possible?
• [ ] Are they sized to actual display dimensions?
• [ ] Is quality between 70 and 85?
• [ ] Do they have explicit width and height attributes (to prevent CLS)?
• [ ] Are they served with appropriate cache headers?

Get those right and your Largest Contentful Paint will drop dramatically, often without any other optimization needed.