Compress Images Without Losing Quality

“Compress without losing quality” sounds like a contradiction, but it’s the normal case: most images carry far more data than the human eye can perceive. The trick is knowing which data to throw away. Here’s how compression actually works and how to do it well.

Lossy vs lossless: the two kinds of compression

Lossless (PNG, WebP-lossless) shrinks files by encoding the same pixels more efficiently — like a ZIP file for images. Quality is bit-for-bit identical, but savings are modest: typically 10–30%.

Lossy (JPG, WebP, AVIF) discards visual information the eye barely notices — subtle color variations, fine high-frequency detail. Savings are enormous: 60–90% smaller files. The art is discarding the right information.

For photos, lossy is almost always the answer. For logos and text, lossless (or careful lossy) is required.

What the quality slider actually does

A JPG “quality 90” doesn’t mean “90% as good.” The scale is arbitrary and non-linear:

• 95–100: Effectively transparent. Files still large. Useful only as a master/export before further editing.
• 85–92: The sweet spot for photos. Visually indistinguishable from the original in normal viewing; files 60–80% smaller than the uncompressed source.
• 70–84: Fine for web thumbnails and social posts. Slight softening visible only when pixel-peeping or on high-DPI screens.
• Below 70: Blockiness, banding in gradients, and smearing around sharp edges become obvious. Avoid for anything important.

Concrete example: a 12 MP smartphone photo might be 6 MB straight from the camera. At JPG quality 90 it’s ~1.5 MB with no visible difference. At quality 80 it’s ~800 KB — fine for a blog post. That’s an 87% reduction for zero perceived loss in the first step and negligible loss in the second.

Where quality loss actually shows

Compression artifacts aren’t evenly distributed. They concentrate in:

1. Smooth gradients (skies, studio backdrops) — banding appears as visible steps between tones.
2. Sharp edges against flat backgrounds (text on white, logos) — ringing/halo artifacts.
3. Fine repetitive detail (fabric, foliage, hair) — gets smeared into mush first.

This is why a single quality setting doesn’t fit all images: a portrait at quality 75 looks perfect, while a screenshot of a spreadsheet at quality 75 looks terrible. Judge per image, zoomed to 100%.

A practical workflow

1. Start from the best source. Compress from the original or highest-quality export, never from an already-compressed copy. Re-compressing a JPG (“generation loss”) stacks artifacts fast.
2. Resize first. A 4000 px image shown at 800 px wastes bytes regardless of quality. Resize to the actual display dimensions first — this alone often cuts more bytes than any quality tweak.
3. Pick the right format. For photos on the web in 2026, WebP beats JPG by ~30% at equal quality. See our format comparison for the full breakdown.
4. Dial in quality visually. Start at 85, zoom to 100% on the trickiest part of the image (sky, text edges), and lower it until you just notice degradation — then go back up one step.
5. Strip metadata. EXIF data (camera settings, GPS, thumbnails) can add tens of kilobytes. Our compressor and EXIF remover handle this.

A batch workflow that actually works

Compressing one image is trivial. Compressing 300 wedding photos without losing your mind takes a system:

1. Copy, don’t move. Work on a copy of the folder. Your originals are the backup; never batch-process the only copy.
2. Sort by content type first. Split photos from graphics/screenshots into separate folders. They need different settings (photos: JPG/WebP quality 80–85; graphics: PNG or WebP lossless), and mixing them means either blurry text or bloated photos.
3. Resize before compressing. This is the step people skip. If the images are for a blog that displays at 800 px wide, batch-resize everything to 1600 px (2× for retina) first. Resizing a 4000 px photo to 1600 px cuts ~84% of the pixels — no quality setting can compete with that.
4. Compress with a preview. Run a batch through our compressor, spot-check the most detailed 2–3 images at 100% zoom, and adjust quality once for the whole batch.
5. Name outputs clearly. photo.jpg → photo-web.jpg or into a separate compressed/ folder. Future you will thank present you when the CMS asks for the original.

This whole pipeline runs in the browser with our tools — resize, then compress, then download as a batch. No uploads at any step, so client work and personal photos stay private throughout.

Doing it in your browser

Our image compressor runs entirely client-side:

1. Drop images onto the page (JPG, PNG, WebP supported, batch included).
2. Move the quality slider and watch a live side-by-side preview with file sizes.
3. Download the compressed versions — individually or all at once.

Because it never uploads anything, you can compress sensitive images (client work, personal photos) without a second thought, and there’s no queue or file-size cap imposed by a server.

Common mistakes

• Compressing twice. Every lossy save degrades the image. Keep a high-quality master; export compressed copies from it.
• Using JPG for screenshots. Text and UI elements compress badly as JPG. Use PNG or WebP for anything with sharp edges — more in JPG vs PNG.
• Ignoring responsive sizes. Serving one 2400 px image to phones and desktops wastes mobile data. Generate 2–3 sizes; the <img srcset> attribute makes this painless.
• Chasing the smallest file. Below a point, you’re trading visible quality for kilobytes nobody’s connection needs anymore. Optimize for the perceptual threshold, not the byte count.

How small is small enough?

Rules of thumb for the web in 2026:

• Hero/banner image: under 200 KB (WebP/AVIF)
• Blog content image: under 150 KB
• Thumbnail: under 50 KB
• Product photo: under 300 KB at 1600 px wide

Hit those and your images stop being the thing that slows your site down.