ImagePal
All guides
How-tohow-toperformancecompression

How to compress images for the web without losing quality

4 min read

Web images are the single biggest reason web pages are slow. According to the HTTP Archive, images account for roughly half of all bytes downloaded on a typical page. That's also where the easiest performance wins live — most images on the web are 2× to 10× larger than they need to be, and shrinking them costs nothing in visible quality.

This guide gives you a four-step workflow that takes most images from 'too big' to 'fast' without sacrificing the quality your visitors actually see. It works whether you're processing one image or a thousand.

The 4-step web image workflow

In order — each step compounds with the next:

Step 1: Resize to display dimensions

This is the biggest single win, and the one most people skip. If your image will be displayed at 800 pixels wide, save it at 800 pixels wide (or up to 1600 wide for retina/high-DPI displays). A 4000-pixel-wide source image contains 25× more pixels than an 800-pixel one — and 25× more pixels means roughly 25× more bytes, no matter how cleverly you compress them.

Common display widths to target:

  • Hero images / above-the-fold: 1600px wide (covers retina laptops at 800px display).
  • Content / blog body images: 1200px or 1600px wide.
  • Card thumbnails: 600–800px wide.
  • Avatars and icons: 200–400px square.

Step 2: Choose the right format

Pick based on the image content and browser support requirements:

  • Photographs → AVIF (smallest), WebP (safer fallback), or JPEG (universal). For modern web in 2026, AVIF with WebP fallback is ideal.
  • Graphics, logos, screenshots → PNG or lossless WebP.
  • Anything with transparency → PNG, WebP, or AVIF (not JPEG).
  • Animations → AVIF or WebP, never GIF for new content.

If you're publishing through a modern CMS or framework, it likely handles format conversion automatically — you upload a JPEG, it serves WebP/AVIF to capable browsers. Worth checking before you do it manually.

Step 3: Compress with the right quality setting

The quality slider is a curve, not a line. Here's roughly how it behaves for JPEG and WebP:

  • Quality 100: maximum size, no compression artifacts. Almost always overkill for the web.
  • Quality 90: ~30–40% smaller than 100, still visually identical to most people.
  • Quality 75–80: ~60–70% smaller than 100, no visible loss in normal viewing. The sweet spot.
  • Quality 60: ~75% smaller, slight loss visible if you look for it.
  • Quality 50 and below: visible compression artifacts, especially on edges and text.

Default to 75. It's the right answer for the vast majority of web photos. For AVIF, the equivalent target is roughly quality 50–60 (different encoders use different scales).

Step 4: Strip metadata

JPEGs straight from a phone or camera carry EXIF metadata: GPS coordinates, camera model, exposure settings, sometimes a thumbnail copy of the image. For web display, none of this is needed — and the GPS data is a privacy concern. Stripping metadata typically saves another 5–20KB per image and removes any embedded location information.

Most compression tools strip metadata by default; check the tool's documentation if you're not sure.

Quality settings: a practical reference

Concrete recommendations by image type:

  • Hero photos: WebP/AVIF quality 75. Target file size: under 200KB at 1600px wide.
  • Body content photos: WebP/AVIF quality 75–80. Target file size: under 100KB at 1200px wide.
  • Thumbnails: WebP/AVIF quality 70. Target file size: under 30KB at 600px wide.
  • Logos and icons: PNG or lossless WebP. Target: as small as the format allows (no quality slider).
  • Screenshots of UI/text: PNG, then run through pngquant or similar to reduce palette. Often shrinks 50–70% with no visible change.

Common pitfalls

  • Compressing the same image twice. Each round of lossy compression discards more information. Always work from an original; don't compress an already-compressed file.
  • Trusting the 'export for web' preset. Some tools default to quality 90 or 100. Always check the actual file size.
  • Forgetting retina sizes. Modern phones and laptops have high-DPI displays. An image that looks crisp at 800px on a desktop monitor will look soft on a retina laptop. Either serve 2× sizes via srcset, or default to 1.5× the display size.
  • Compressing PNGs with JPEG compression. PNGs don't have a 'quality' slider in the same sense; they need PNG-specific tools (pngquant, OxiPNG) to compress meaningfully.
  • Shipping the source resolution. A full-resolution phone photo is often 12MP — 4000×3000 pixels, 4–8MB. Never serve this directly to a web page.

Verifying your results

Two quick checks after compressing:

  1. Look at the image at its actual display size, not zoomed in. Compression artifacts that are visible at 4× zoom usually aren't at 1×. The user will never zoom in.
  2. Run your page through Lighthouse (Chrome DevTools → Lighthouse). Look for the 'Properly size images' and 'Efficiently encode images' suggestions. They'll tell you exactly which images can be compressed further.

The bottom line

Fast images are mostly about being honest with yourself: the source is too big, the format is wrong, the quality is set higher than it needs to be. Resize first, pick the right format, set quality to 75, strip metadata. That four-step process takes most images from 'page-blocking' to 'forgettable' in seconds, and the visible difference to your visitors is zero.

Compress your images now
Free, browser-based, no upload — start with quality 75.

Frequently asked questions

What's the best compression level for web images?
Quality 75–80 is the sweet spot for JPEG and WebP — most viewers can't see the difference from quality 100, but the file is 60–80% smaller. For AVIF, quality 50–60 produces equivalent visual quality with even smaller files.
Should I resize images before compressing?
Yes — always. A 4000×3000 photo compressed to 200KB is wasteful if it's only ever shown at 800×600. Resize first, then compress. The resize is by far the bigger win on file size.
How small should web images be?
Aim for hero images under 200KB, content images under 100KB, and thumbnails under 30KB. Mobile users especially benefit — every saved kilobyte is faster page load on a 4G connection.
Will compression reduce quality?
Slightly, yes — that's how lossy compression works. But at the recommended quality settings (75–80 for JPEG/WebP), the loss is invisible to the human eye in normal viewing. The quality slider is a curve: the first 20–30% of compression costs almost nothing visually; pushing past 50% starts to show.
Do I need different versions for mobile and desktop?
For best results, yes. Use responsive image attributes (srcset, sizes) to serve different sizes to different devices. A single 'medium' size is a workable compromise if responsive images are too much complexity for your project.

Related guides

Every ImagePal tool runs entirely in your browser. No upload, no account, no tracking.