Image Compression for the Web: How Much Do You Really Save?

Your site's Core Web Vitals are red, your Lighthouse score won't budge above 60, and the audit tool keeps screaming about "properly size images" and "use modern image formats." You compress the worst offender, page weight drops 1.2 MB, and suddenly LCP goes from 3.4 s to 1.8 s. Image compression remains one of the highest-ROI performance wins for any website — but only if you understand what each lever actually does.

This guide measures, in real bytes saved on real images, what JPG quality 80, WebP, AVIF, and aggressive resize each give you. We'll also cover when re-encoding to a "modern" format costs you more than it saves, and how to do all of this browser-side with Ai2Done's Image Compress tool.

TL;DR

• Resize before you compress — a 4000×3000 photo displayed at 800×600 wastes ~95% of its bytes regardless of format. Resize first; compression second.
• JPG quality 80 → 90 is the sweet spot for photos — 50-70% smaller than quality 100, visually identical.
• WebP saves ~25-35% over JPG at the same visual quality. Universal browser support since 2020.
• AVIF saves ~50% over JPG at the same visual quality but adds 5-10× encoding time. Worth it for high-traffic pages.
• Use Ai2Done Image Compress for browser-side compression with side-by-side preview of size vs quality.

Why this is harder than it looks

You'd think "compress this image" is a single decision. In practice, image compression is at least 4 independent levers that interact in unintuitive ways:

1. Dimensions (width × height) — usually the highest-impact lever. A 4000×3000 photo has 16× as many pixels as 1000×750.
2. Format (JPG, WebP, AVIF, PNG) — the encoding method itself.
3. Quality setting (1-100 for JPG/WebP, slightly different for AVIF) — how aggressively the encoder discards information.
4. Color depth and metadata (24-bit vs 8-bit, EXIF stripping, ICC profile) — usually a small but free win.

A naive "compress this image" tool only touches lever 3, leaving the biggest savings on the table. Modern tools — including ours — at least let you pick all four explicitly.

The other source of complication: browser support and your audience. AVIF is amazing in Chrome, Edge, Firefox, and Safari 16+; older Safari needs JPG fallback. WebP is everywhere except IE 11 (which Microsoft dropped support for in 2022 but enterprise sites still see). For most public sites in 2026, WebP is safe; AVIF needs a <picture> element with a JPG fallback.

Real-world measurements: a 3 MB photo, compressed every way

I took a representative test image — a 4032×3024 iPhone shot of a city skyline, 3.1 MB JPG at the camera's default quality (~92). Here's what each lever does in isolation:

The headline: the combination of resize + modern format gives you a 90-95% reduction with no visible quality loss. Either lever alone gets you to 30-45%. This is why your Lighthouse audit is harping on both "properly size" AND "use modern image formats" — they multiply.

Method 1: Ai2Done Image Compress (browser-side, multi-lever)

The Ai2Done Image Compress tool runs all four levers in your browser:

1. Open /tools/image_compress in any modern browser.
2. Drop your image(s) — JPG, PNG, WebP, AVIF, HEIC accepted. Batch upload works for up to dozens of files at once.
3. Pick output format: JPG (universal), WebP (modern, 25% smaller), AVIF (modern, 50% smaller, slower encode), or PNG (lossless, only for diagrams and screenshots).
4. Set quality: 80 is the universal sweet spot for photos. Drop to 70 for thumbnails; raise to 90 for hero images.
5. Optional resize: set max width or max long-edge. Aspect ratio is preserved automatically.
6. Click Compress — for batch jobs, get a ZIP of all the optimised images.

The side panel shows side-by-side preview of original vs compressed at your current settings, with the size in both bytes and visual delta (PSNR, SSIM — perceptual quality metrics). Adjust the quality slider live and see the trade-off in real-time before committing.

Everything runs in your browser. Your photos never upload to a server, including ours. The encoder is mozjpeg-wasm for JPG, libwebp-wasm for WebP, and libavif-wasm for AVIF — all the actual reference implementations, compiled with WASM SIMD acceleration.

Method 2: Squoosh.app (Google's open-source tool)

For a single image with very precise control, Google's Squoosh.app is the most-loved tool in the front-end community. Same architecture (everything in-browser), single-image-at-a-time UX, with extremely granular knobs for every encoder. It's slower for batch (no parallel processing) and the UX assumes you know what mozjpeg's chroma subsampling does — but for the rare "I need to perfectionist-tune one hero image," it's unbeatable.

Method 3: imagemin in your build pipeline

For automated optimisation as part of your site build:

npm install --save-dev imagemin imagemin-mozjpeg imagemin-webp imagemin-avif

# in your build script
import imagemin from 'imagemin';
import imageminMozjpeg from 'imagemin-mozjpeg';
import imageminWebp from 'imagemin-webp';

await imagemin(['src/images/*.{jpg,png}'], {
  destination: 'build/images',
  plugins: [
    imageminMozjpeg({ quality: 80 }),
    imageminWebp({ quality: 80 }),
  ]
});

This is the right answer for serious sites that update images frequently — the optimisation runs every build, no manual step. For one-off image batches or "I added one hero image to my site," the browser tool is faster.

Method 4: Next.js / Astro / framework-built-in image optimisation

Modern frameworks ship built-in image optimisation that handles the whole "resize + serve modern format with fallback" pipeline:

• Next.js: <Image> component auto-generates srcset, serves WebP/AVIF with JPG fallback, and lazy-loads.
• Astro: <Image> component does the same.
• Gatsby: gatsby-plugin-image does the same.
• Cloudflare Images: serve any source image through a transform URL — ?width=800&format=auto and get the right size in the right format for each visitor.

If you're building a new site, use the framework's built-in handler. For a static or legacy site, browser/CLI compression is the path.

How we built the browser compressor (technical deep-dive)

The Ai2Done Image Compress tool is built on three WebAssembly encoder modules:

• mozjpeg-wasm (Mozilla's JPEG encoder, ~10% better than libjpeg-turbo at the same quality)
• libwebp-wasm (Google's reference WebP implementation)
• libavif-wasm (the AV1 image format encoder, ~5-10× slower than JPG but produces the smallest files)

For decoding (input side), we use the browser's built-in Image and createImageBitmap for JPG, PNG, GIF, WebP, BMP, and ICO — no extra dependencies. HEIC goes through libheif-wasm (~5 MB extra bundle, lazy-loaded only when an HEIC upload is detected).

The interesting design choice: side-by-side live preview. As you drag the quality slider, both panels update at ~60fps (small images) or ~10fps (large images), using an OffscreenCanvas and a debounced re-encode in a Web Worker so the UI never stalls. This is what lets you find the sweet spot in seconds instead of guessing-then-checking.

For batch jobs, we use a Web Worker pool sized to navigator.hardwareConcurrency - 1 so 8 images encode in parallel on an 8-core machine. AVIF encoding is the bottleneck — we cap parallelism at 2 for AVIF to avoid OOMing low-end devices.

FAQ

Q: Should I always use AVIF for everything? A: Not always. AVIF gives ~50% smaller files at the same visual quality, but encoding takes 5-10× longer than JPG. For static high-traffic pages, the encoding cost is one-time and the bandwidth savings are forever — worth it. For dynamically-generated images (per-user content, real-time previews), the encoding cost matters more, and WebP is the better trade.

Q: Will WebP / AVIF work in all browsers? A: WebP works in every browser shipped since 2020 — Chrome, Edge, Firefox, Safari 14+, Opera. AVIF works in Chrome, Edge, Firefox, and Safari 16+. For Safari <16 visitors (~3% of traffic in 2026), serve a JPG fallback via <picture><source srcset="hero.avif" type="image/avif"><img src="hero.jpg"></picture>.

Q: Does compressing strip EXIF / GPS / camera data? A: By default, our tool strips all metadata (smaller files, no GPS leak). Toggle "Preserve EXIF" if you want to keep camera settings or orientation tags. For images you'll share publicly, default-strip is the right choice — GPS metadata in social-shared photos has caused real privacy incidents.

Q: What's the difference between JPG quality 80 and JPG quality 90? A: At quality 90, the file is ~50% larger than at quality 80 for visually identical output on most photos. Quality 80 is the universal "you cannot see the difference unless you zoom in 4×" sweet spot. Use 90+ only for images that will be re-edited downstream (each edit pass adds quality loss; starting from quality 90 gives more headroom).

Q: Will compressing a photo to JPG quality 80 hurt my SEO? A: The opposite — faster page loads improve SEO. Google's Core Web Vitals (especially LCP) factor into ranking. Image weight is usually the #1 cause of slow LCP. A 50% smaller hero image often means a half-second faster LCP, which Google rewards.

Q: I have 1000 product photos for an e-commerce site. Can I batch them all? A: Yes, but break into batches of 50-100 to avoid browser memory pressure. Drop 100 images, get a ZIP, repeat. For an automated pipeline, set up imagemin in your build (see Method 3).

Try it now

Compress images for the web in seconds, with side-by-side preview:

Open the Image Compress tool →

Drop images, pick format, drag the quality slider, watch the bytes drop. No upload, no signup.

Related reading

• HEIC to JPG conversion: the right way on every device — for iPhone photos that need format conversion before compression
• Upscale images 4× with browser-side AI (no signup) — when you need more pixels, not fewer
• Image OCR: extract text from any picture in 100+ languages
• Browse all image tools on the main site

Last updated 2026-06-14. The Image Compress tool runs 100% in your browser — your photos never leave your device. We never collect, log, or analyse the files you process.