I once spent a full afternoon convinced a client's site was slow because of a rendering bug in my React code. Profiled the components, memoized things, chased re-renders. The actual problem was a background hero image: a 3.1 MB JPEG saved at 100% quality, when the exact same image at 80% quality would have been 480 KB and looked identical. I had over-engineered the app and under-thought the assets. That's a very developer way to waste a day.
Since then, image compression has been the first thing I check, not the last. It's also the most misunderstood — "compress without losing quality" gets treated like a paradox, when really it's just a matter of knowing which lever discards data and which one doesn't. This guide is the mental model I use, built while shipping toolz.dev and tuning Core Web Vitals on client sites: how compression actually works, when to use lossy versus lossless, and why one specific quality number keeps winning.
TL;DR: Use Image Compress at around 80% quality for web photos — that's the sweet spot where the file shrinks 60–80% and you still can't tell it apart from the original at normal size. Compress from the original (never re-compress a JPEG), and always resize to display dimensions before compressing. For maximum savings, convert photos to WebP first. Everything runs in your browser — nothing uploads.
What's Actually Happening When You Compress an Image?
A digital image is a grid of pixels, each storing color. That's why raw images are enormous. A 1920×1080 image at 24-bit color is:
1920 × 1080 × 3 bytes = 6,220,800 bytes ≈ 5.93 MB
Nearly six megabytes for one picture. A page with ten of them would be 60 MB of downloads before a line of text loads. Compression exists to make that survivable, and it does so in one of two fundamentally different ways.
Lossless compression finds patterns in the data and encodes them more compactly, without discarding anything. The decompressed image is pixel-for-pixel identical to the original. The techniques are elegant: run-length encoding collapses "red, red, red, red, red" into "5× red"; dictionary coding (the Deflate algorithm at PNG's core) replaces recurring patterns with short codes; prediction filtering stores each pixel as its difference from a predicted value, so smooth gradients become long runs of tiny numbers that compress beautifully. PNG, lossless WebP, and lossless AVIF all work this way.
Lossy compression achieves far bigger savings by throwing away data your visual system is unlikely to notice — and it's cleverer than "delete some pixels." It converts the image from RGB to a luminance-plus-color model (your eye is far more sensitive to brightness than to color), then reduces the resolution of the color channels while keeping brightness sharp. It breaks the image into blocks, transforms each into frequency coefficients, and rounds the high-frequency ones — the subtle textures and noise — down to fewer values. That rounding step, quantization, is where data is actually lost. JPEG, lossy WebP, and lossy AVIF all follow this arc.
The practical upshot: lossless is for images where every pixel is meaningful — logos, screenshots, diagrams, anything with crisp text. Lossy is for photographs and natural images, where "looks identical" matters far more than "is bit-for-bit identical."
What Do the Quality Settings Actually Mean?
"Quality 80%" is a number people set without knowing what it buys them. Here's the map I use for JPEG and lossy WebP, based on a lot of before-and-after comparisons at real viewing size.
100% (maximum): Almost never the right choice. The file is often 3–5× larger than 80% with no visible improvement. That afternoon-wasting hero image was saved here.
85–95% (high): For photography portfolios and images where subtle detail genuinely matters. At 90%, artifacts are invisible to most viewers even at 100% zoom.
75–85% (the web sweet spot): 60–70% smaller than maximum, with artifacts invisible at normal viewing size. This is where almost all web images belong.
50–75% (aggressive): For thumbnails and previews where size is critical. Artifacts start showing in smooth gradients and fine textures if you look closely.
Below 50%: Visible blockiness and color banding. Reserve it for genuinely low-priority images or hard size constraints.
PNG doesn't have a "quality" slider because it's lossless — you optimize it differently. The compression level (0–9) trades encoding time for a smaller file, with 6 a sensible default. Reducing color depth helps enormously when an image uses few colors: a 16-color logo dropped from 24-bit to 8-bit shrinks dramatically with zero visible change. And stripping metadata — EXIF, color profiles, timestamps — trims bytes that never affected the picture.
WebP is my default for the web: at quality 80 it runs 25–35% smaller than JPEG at equivalent quality, and it also does a lossless mode that beats PNG by roughly a quarter. AVIF compresses harder still — commonly 50%+ smaller than JPEG — but encodes more slowly and isn't quite universally supported, so I serve it with a WebP fallback rather than alone.
Which Format Should You Compress To?
Picking the format is half the compression battle, and the decision is simpler than the options make it look. Here's the comparison I'd hand a new teammate:
| Format | Type | Vs. JPEG size | Transparency | Best for |
|---|---|---|---|---|
| JPEG | Lossy | baseline | No | Photos in email, universal fallback |
| PNG | Lossless | Much larger for photos | Yes | Screenshots, logos, text, diagrams |
| WebP | Both | 25–35% smaller | Yes | Default for web photos and graphics |
| AVIF | Both | ~50% smaller | Yes | Max savings, with a WebP fallback |
The single most common format mistake — and I've caught it in code review more times than I can count — is saving photographs as PNG. Because PNG is lossless, a photo saved as PNG can be many times larger than the same photo as an 85%-quality JPEG with no visible difference. PNG is for graphics with hard edges and text, not for natural images. Use JPEG or WebP for photos and you reclaim most of a bloated page's weight in one change.
Converting is a two-click job on the Format Converter. The pattern I actually ship lets the browser negotiate:
<img src="photo-800.webp"
srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1600.webp 1600w"
sizes="(max-width: 600px) 400px, 800px"
alt="Description">
That srcset hands the browser several sizes and lets it download the one that fits the device, so a phone never pulls the desktop image. Combined with the right format, it's the difference between a fast site and a slow one.
What's the Correct Order to Compress Web Images?
Order matters more than any individual setting, and getting it wrong is the quiet mistake behind most "I compressed it and it's still huge" complaints. The sequence, every time:
Resize first. Compressing a 4000×3000 image that will display at 800×600 wastes effort on pixels about to be discarded, and the result is still far bigger than necessary. Resize to the display dimensions (double for Retina) before touching the compressor. This one reordering fixes more oversized-image problems than any quality tweak.
Convert second. Move photos to WebP (or AVIF with a fallback) using the Format Converter. You're now compressing the smaller, better-formatted image.
Compress third. Run Image Compress at around 80% for lossy web images, then judge the result at actual viewing size — not zoomed to 400%, because nobody views a webpage that way.
To make that concrete, here's the web-optimization pass I run on a real page: audit with Lighthouse to find the heavy images, resize each to its display size, convert to WebP, compress at 75–80%, then re-run Lighthouse to confirm. The typical outcome is 50–80% off total image weight and a measurable jump in Largest Contentful Paint — which is the metric that sent me down this whole path in the first place.
For a broader tour of resizing, format choice, and background removal alongside compression, the image tools guide covers the full toolkit.
Which Compression Mistakes Cost the Most?
A handful of errors account for most wasted bytes and most visible quality damage. I've made every one of these.
Re-compressing an already-compressed JPEG. Each round of lossy compression stacks new artifacts on top of the old ones, and the damage is cumulative and permanent. Always compress from the original source, and keep those originals — generate every compressed version from them, never from a previous compressed copy.
Using PNG for photographs. Covered above, but it's the biggest single win when you spot it: a 5 MB PNG photo becomes a 500 KB JPEG with no visible difference.
Over-compressing. Dropping JPEG to 30% makes tiny files with visible blockiness and banding. Stay at 75–85% for web and test at real size to find your floor.
Skipping the resize step. Compressing before resizing, as covered above, produces files that are both larger and lower quality than they should be.
Ignoring modern formats. Serving JPEG when WebP is available leaves 25–35% of potential savings on the table for no reason.
If you want to check your work objectively, perceptual metrics exist — SSIM above 0.95 is generally "visually lossless," and Google's Butteraugli scores under 1.0 mean differences are essentially invisible — but honestly, for day-to-day work, viewing the original and the compressed version side by side at actual size tells you almost everything the math would.
Frequently Asked Questions
How do I compress images without losing quality?
For true, pixel-perfect lossless compression, use PNG or lossless WebP. For "visually lossless" — no difference you can see — use JPEG or WebP at 80–90% quality. The Image Compress tool lets you set the quality and compare the original against the compressed version before you download, so you can find the exact point where size drops but the image still looks untouched.
Why is 80% quality considered the magic number?
Across a lot of before-and-after testing at real viewing size, JPEG or WebP quality around 80% is where the file has shrunk 60–70% from maximum but the artifacts are still invisible without pixel-peeping. Go higher and you pay a lot of bytes for detail no one sees; go much lower and gradients start to band. It's the best balance for web use, which is why it's the default I reach for.
What is the best image format for websites in 2026?
WebP is the best default — roughly 25–35% smaller than JPEG with effectively universal browser support. For maximum savings, use AVIF (about 50% smaller than JPEG) served with a WebP fallback in a <picture> element. Convert with the Format Converter. Keep genuine vector art like logos as SVG rather than compressing them as raster.
What is the difference between lossy and lossless compression?
Lossless compression rearranges data more efficiently without discarding any of it, so the result is pixel-for-pixel identical to the original — PNG works this way. Lossy compression permanently removes data your eye is unlikely to notice, achieving far higher savings — JPEG works this way. Lossless typically yields 10–40% reduction; lossy commonly yields 60–90%. Use lossless for text and graphics, lossy for photographs.
Should I resize an image before or after compressing?
Always resize first. Compressing a large image and then shrinking it wastes compression effort on pixels that the resize discards, leaving a file that's both bigger and lower quality than it should be. Resize to the display dimensions first, then compress the smaller image — that order produces the smallest, cleanest result.
Is it safe to compress images with an online tool?
Most online compressors upload your images to their servers to process them, which is a concern for personal photos or client work. The Image Compress tool on toolz.dev runs entirely in your browser using the canvas API, so your images never leave your device — safe for anything private or proprietary.
Why is compressing the same image twice a bad idea?
Lossy compression discards detail, and doing it twice discards it twice — the second pass adds fresh artifacts on top of the first pass's, and none of it comes back. This is why you should always keep the original and generate every compressed version from it, rather than compressing a file that was already compressed once.
How do I know if my images are too large?
Run Google Lighthouse or PageSpeed Insights against your page; both flag oversized images and suggest better sizes. A quick rule of thumb: if any single image is over 200 KB, it's worth optimizing, and hero images especially should sit well under that since they drive Largest Contentful Paint. Feed the offenders through the resize-convert-compress workflow and re-audit.
How do I compress an image to a specific file size like 200 KB or 1 MB?
Resize to the display dimensions first, then step the quality down until you clear the target: start at 80%, and if you're still over, try 70%, then 60%. The Image Compress tool shows the output size as you move the slider, so you can watch it cross the threshold rather than guessing and re-exporting. Switching the format to WebP usually buys you another 25–35% at the same quality setting, which is often enough on its own.
Does compressing an image reduce its resolution or dimensions?
No — compression and resizing are separate operations. Compressing a 3000×2000 photo leaves it 3000×2000; it just stores those pixels using fewer bytes, at the cost of some fine detail. If you want fewer pixels, that's a resize, and it's the change that usually saves the most weight. Doing both, in that order, is what turns a 6 MB camera file into a 90 KB web image.
