Somebody once told you to "compress your images," and somewhere along the way you got the impression that compression is a tax you pay in quality to get a smaller file. That's not quite right, and the gap between that belief and what's actually happening is exactly why people either over-compress and ruin their photos, or under-compress and ship files three times larger than they need to be.
Compression isn't a single dial between "good" and "small." It's a threshold. Below a certain point, you lose nothing a human eye can detect. Cross it, and the damage shows up fast — blotchy skies, smeared text, blocky edges around faces. This guide is about finding that threshold deliberately, instead of guessing.
What compression actually does to a file
An uncompressed image stores the colour value of every single pixel independently. A 12-megapixel photo has roughly 12 million pixels, each one needing its own colour data — that adds up fast, which is why raw, uncompressed image data is enormous.
Compression works by finding patterns in that data and storing them more efficiently. A clear blue sky doesn't need 2 million individually-recorded pixel values if most of them are nearly identical — the algorithm can record "this region is approximately this shade of blue" instead, and reconstruct something visually identical from far less data. That's the basic principle behind every lossy compression format, including JPG and WebP.
The "lossy" part means some of that original precision is genuinely gone, replaced by an approximation. The skill is making that approximation good enough that the difference is imperceptible — not eliminating the approximation entirely, which isn't really what compression is for.
Why "zero quality loss" is the wrong goal
If you want mathematically perfect, bit-for-bit lossless compression, that exists — it's what PNG does. The trade-off is that lossless compression can only shrink a file by finding genuine redundancy in the data, and photographs don't have much of that. A complex photograph compressed losslessly might shrink by 10 to 20 percent. That's not nothing, but it's nowhere near what most people actually need.
Lossy compression at a sensible quality setting routinely shrinks a photo by 60 to 80 percent with no visible difference. Lossless compression shrinks it by 10 to 20 percent with no difference at all, visible or otherwise. For almost every real use case — web images, email attachments, app uploads — the lossy result at the right setting is the better trade, because the "loss" in question is invisible anyway.
Chasing literal zero-loss compression for a photograph usually means accepting a file far larger than necessary, in exchange for a guarantee you didn't need. The real goal isn't "no loss." It's "no loss anyone will ever notice," and that's a meaningfully easier target to hit well.
Where the visible-damage threshold actually sits
This varies by image content, but it's far more predictable than most people assume. For JPG and WebP, quality is set on a 0–100 scale, and the visible-damage threshold for typical photographs sits in a fairly narrow band.
Where artifacts become visible, by quality setting
Below roughly quality 50, you start seeing blocky artifacts around hard edges, colour banding in gradients like skies, and a general loss of fine texture — skin, fabric, foliage all start looking smeared. Between 60 and 75, most people won't notice on a quick glance but will see it if they zoom in or compare side by side with the original. From 80 upward, the difference becomes genuinely difficult to spot even when deliberately looking for it.
The specific content of the image matters too. A close-up portrait with skin texture and fine hair detail shows compression artifacts sooner than a wide landscape photo with smooth gradients. If you're compressing something detail-heavy, lean toward the higher end of the safe range.
Lossy vs lossless, in practical terms
| Property | Lossy (JPG, WebP) | Lossless (PNG) |
|---|---|---|
| Typical size reduction | 60-80% | 10-20% |
| Data discarded | Yes, by design | None, ever |
| Best for | Photographs, complex images | Screenshots, logos, text, flat colour |
| Repeated re-saving | Degrades further each time | No degradation, ever |
| Transparency support | WebP yes, JPG no | Yes |
This is also why the right compression strategy depends on what's actually in the image, not just a single universal setting. We covered the broader format decision in detail in JPG vs WebP vs PNG — that's the right read if you haven't settled on a format yet. This guide assumes you already know which format you're using and want to get the compression setting right within it.
The right setting for what you're actually doing
Product photography
Customers zoom in and inspect detail. Compression artifacts here directly cost trust and sales — err high.
Blog and content images
Viewed briefly, rarely zoomed. Page speed matters more here than the last few percent of fidelity.
Thumbnails & previews
Small display size hides artifacts that would be obvious at full size. Compress aggressively here.
Email attachments
Balances file size against many providers' attachment limits, while staying clean on a normal screen.
How much smaller your file will realistically get
Expectations matter here, because results vary more than people assume based purely on image content rather than the setting alone.
- Photos with smooth gradients — clear skies, plain backgrounds, soft lighting — compress further before any visible change, often 70-80% smaller at quality 80.
- Photos with fine detail — foliage, fabric texture, busy backgrounds — compress less before artifacts appear, typically 50-65% smaller at the same setting.
- Screenshots and graphics with text — compress poorly under lossy formats regardless of setting, since sharp edges are exactly what lossy compression struggles with. These belong in PNG, not JPG or WebP.
Compress the same image at 90, 75, and 60. Open all three at actual size, not thumbnail size, and compare. The point where you first notice a difference from the original is your real threshold for that type of image — and it's usually higher than people expect, which is exactly why over-compression is the more common mistake.
Compressing your first batch properly
-
1Sort images by how they'll actually be viewed
A thumbnail and a hero image don't belong at the same quality setting. Group them before you start, not after you notice the hero image looks rough.
-
2Resize to final display dimensions first
Compressing a 4000px-wide image that will display at 800px wastes the compression step entirely, since the eventual resize changes the pixel data anyway. Get the image to its real size before compressing it.
-
3Pick a starting quality based on the use case table above
Start with the recommended range rather than guessing from zero each time.
-
4Compress with Humanify's Image Compressor
Free, runs entirely in your browser, no upload — drop in your images and adjust the quality setting directly against the live preview.
-
5Spot-check at actual display size
Not thumbnail size in a file browser — the real size the image will appear at. This is the only way to catch a setting that's too aggressive before it goes live.
Ready to compress your first batch? Drop in your images and adjust quality against a live preview.
Open Image CompressorMistakes that cause real, visible damage
- Using one quality setting for every image regardless of content, instead of accounting for detail level and how the image will be viewed
- Re-saving the same lossy file multiple times across different tools, compounding generational loss with every pass
- Compressing before resizing, which wastes the compression step entirely once the image is resized afterward
- Using a lossy format for screenshots, logos, or text, where lossless formats like PNG perform far better at any reasonable size
- Judging compression quality from a thumbnail preview instead of the image's actual display size
- Treating "zero quality loss" as the goal, leading to unnecessarily large files for no perceptible benefit
What to do before and after compressing
Two habits worth building into the same workflow as compression itself, since you're already handling the file anyway.
Before compressing, check what's actually in the file. If the photo is going anywhere outside a closed circle of people you trust, it's worth knowing whether it carries hidden location or device data — this is a separate concern from file size, covered in full in why your photos are leaking your location. Compression and metadata removal solve different problems and are worth doing together rather than treating compression as a complete "prepare this image" step on its own.
After compressing, keep your original. Always store the source file before compression separately. If a setting turns out too aggressive for a particular use case later, or the image needs to go somewhere requiring higher fidelity, you want the uncompressed version available rather than working backward from an already-compressed file.