How to compress images

A 4MB hero image on your landing page is the fastest way to lose mobile visitors. Google’s own data shows bounce rate climbing sharply once page weight crosses 2MB on 3G — and an unoptimized iPhone photo alone often weighs more than that. The fix is image compression, which sounds simple but hides real tradeoffs: lossy versus lossless, JPEG quality sliders, WebP adoption, PNG optimization, EXIF stripping, and the difference between “looks fine” and “ships fast.” This guide covers how each compression mode actually works, the target file sizes for different page contexts, why mobile and desktop need different settings, and the small details that separate professional compression from the default export.

Lossy vs lossless

Lossy compression discards information the human eye is unlikely to notice — subtle color gradations, high-frequency details, imperceptible hues — to achieve dramatic size reductions. JPEG, WebP (lossy mode), and AVIF are lossy. A typical 12MP photo drops from ~10MB raw to 1–3MB at high quality, 200–500KB at mid quality.

Lossless compression keeps every pixel intact; it just encodes them more efficiently. PNG, WebP (lossless mode), TIFF, and FLIF are lossless. Size reductions are smaller — typically 10–40% — but the output is pixel-identical to the input. Use lossless for screenshots, diagrams, and anything with text, hard edges, or transparency.

JPEG quality: what the slider actually does

JPEG quality is a number from 0 to 100 that controls how aggressively the DCT coefficients get quantized. It’s not a linear scale. The sweet spot for web photos is 75–85. Below 60 you start seeing visible block artifacts in flat areas like sky gradients. Above 90 you’re adding file size with almost no perceptible quality gain.

Quality  Typical 1920x1080 photo size
100      1.8 MB    (wasteful)
95       900 KB
85       430 KB    (recommended for photos)
75       280 KB    (web default)
60       170 KB
50       140 KB    (visible artifacts)
30       90 KB     (clearly degraded)

Save once from the source at quality 85. Never re-save a JPEG at high quality expecting to recover detail — once it’s gone, it’s gone, and each re-encode introduces additional loss (“generation loss”).

WebP: the modern default

WebP beats JPEG at the same visual quality by roughly 25–35% file size, and adds transparency support. It’s been supported by all major browsers since 2020, so there’s no practical reason not to ship it. A 430KB JPEG at quality 85 is typically a 290KB WebP at the same visual fidelity.

The usual pattern: serve WebP with a JPEG fallback using <picture>, or let a CDN handle content negotiation via the Accept header. AVIF is even smaller (~50% of JPEG) but has slower encoding and lower tooling support — use it for your largest images only.

PNG optimization

PNG is lossless, which means “compression” means finding a better encoding, not discarding data. Key knobs: color palette reduction (PNG-24 truecolor to PNG-8 palette can cut size by 70% if the image has fewer than 256 distinct colors — icons and diagrams often do), filter and compression level (zlib levels 0–9; 9 is slowest and smallest), and chunk stripping (removing metadata chunks like tEXt and iTXt).

Tools like pngquant and oxipng can reduce a typical PNG screenshot by 40–70% with no visible change. For photographic content, always prefer JPEG or WebP over PNG — PNG-on-photos is 5–10x the file size of JPEG for the same perceived quality.

Target sizes by context

Context             Target size       Format
Hero image          150-400 KB        WebP or JPEG q80
Blog inline photo   80-200 KB         WebP or JPEG q80
Thumbnail           15-40 KB          WebP
Product grid        50-120 KB         WebP
Social share (og)   200-400 KB        JPEG q85, 1200x630
Email newsletter    max 100 KB each   JPEG q75
Favicon             < 10 KB total     PNG or ICO
Mobile app icon     40-80 KB          PNG-8

These are photo-realistic targets. Flat illustrations in SVG ship at 2–10KB and should almost always be used over raster for logos, icons, and diagrams.

Resolution before compression

Compressing a 6000×4000 image to 200KB damages it more than resizing first to 1920×1280 and compressing. The compressor has fewer pixels to work with, so the per-pixel bitrate is higher. Always resize to the display dimension (or 2x for Retina) before compressing. A 400px-wide card thumbnail doesn’t need a 4000px source.

Mobile vs desktop

A desktop visitor on fiber can absorb a 500KB hero image without noticing. A mobile visitor on a rural 4G tower feels every extra 100KB. Use responsive images with srcset to serve smaller files to smaller screens:

<img
  src="hero-1280.webp"
  srcset="hero-640.webp 640w,
          hero-960.webp 960w,
          hero-1280.webp 1280w,
          hero-1920.webp 1920w"
  sizes="(max-width: 768px) 100vw, 1280px"
  alt="..."
  loading="lazy">

This serves a 60KB 640-wide file to phones and a 350KB 1920-wide file to desktops from the same markup. The loading="lazy" attribute defers offscreen images until scroll.

EXIF stripping

Photos from phones and cameras carry EXIF metadata: GPS coordinates, camera model, lens, exposure settings, sometimes the photographer’s name. This adds 5–50KB per image and, more importantly, can leak location data you didn’t intend to publish — a photo of your kid’s birthday party can geotag your home address. Strip EXIF on any image going to the public web unless you have a specific reason to keep it (photojournalism, stock photography attribution).

Progressive JPEG

A progressive JPEG loads in layered passes — blurry preview, then sharper, then final — instead of top-to-bottom. On slow connections the user sees something meaningful fast. File size is nearly identical to baseline JPEG (often slightly smaller). Most encoders have a “progressive” or “interlaced” checkbox; turn it on.

Batch compression

For an existing site with hundreds of uncompressed images, run a one-time batch pass with tools like sharp, imagemin, or squoosh-cli. A reasonable pipeline: resize to max 1920 wide, convert to WebP at quality 80, write both WebP and a JPEG fallback, strip EXIF. For a marketing site, you’ll typically cut total image weight by 60–80%.

Common mistakes

Saving the same JPEG multiple times. Each re-encode loses quality. Keep a lossless master (PNG or original) and re-export JPEG from that every time.

Using PNG for photographs. PNG is 5–10x larger than JPEG for photos at no perceived quality benefit. Use PNG only for screenshots, diagrams, transparency, or images with sharp text.

Compressing a 6000px source to 200KB. Resize first. The per-pixel quality is far higher when you compress a 1920px image to 200KB than when you squeeze 24 million pixels into the same budget.

Forgetting to set quality explicitly. Default JPEG quality varies wildly across tools — 75 in some, 95 in others. Set it.

Leaving EXIF metadata on public photos. GPS coordinates, device model, and timestamps go out with every upload unless you strip them.

Shipping one size for all screens. A 1920px hero image is overkill on a 375px phone and wastes bandwidth. Use srcset.

Skipping WebP because of “browser support.” WebP has 99%+ global support as of 2024. It’s safe to ship.

Run the numbers

Compress photos without a desktop app using the image compressor. Pair with the image resizer to scale dimensions before compression for dramatic size gains, and the EXIF remover to strip location and device metadata before publishing.