If you’ve ever exported the same photo twice and thought, “Why does this one look… a little sad?”—you’ve already met lossy compression.
And if you’ve ever saved a screenshot as PNG and wondered why it’s the size of a small novel, you’ve met the other side of the family: lossless compression.
This post is here to make the difference feel obvious. Not “codec engineer obvious.” Just regular human obvious, the kind that helps you pick the right option without second‑guessing every export.
The 30‑second definition (the one you actually need)
Lossy compression makes files smaller by removing visual information your eyes are less likely to notice. Great for photos. Dangerous for text, UI, and sharp edges.
Lossless compression makes files smaller by re-encoding the same pixels more efficiently. Nothing is removed. Great for logos, screenshots, and anything you may edit repeatedly.
If you want the quickest mental shortcut:
- Photos → lossy (usually)
- Graphics + text → lossless (usually)
Web.dev phrases it simply: images are often one of the biggest performance levers, and compressing them is one of the easiest wins. (web.dev)
What “lossy” actually changes (and why it still looks fine)
Honestly, “lossy” sounds scarier than it is. The goal isn’t to make your image worse—it’s to remove redundancy and tiny details while keeping the impression the same.
JPEG’s big trick: it edits “detail,” not “objects”
JPEG (the classic lossy format) doesn’t think in terms of “a face” or “a tree.” It breaks the image into small blocks and stores a simplified description of the color/detail in those blocks. When you lower quality, you’re mostly asking it to store less fine detail.
That’s why JPEG artifacts tend to show up as:
- blocky patterns in flat gradients (skies are the usual victim)
- halos around edges
- “mosquito noise” around text or sharp lines
MDN has a good overview of how different image formats behave on the web. (developer.mozilla.org)
Chroma subsampling: the quiet quality killer (for the wrong images)
A lot of JPEG workflows also reduce color detail more than brightness detail (because our eyes are more sensitive to luminance). For photos, this is usually fine. For UI, logos, and text? It can make edges look smeared or dirty.
If you’ve ever seen red text on a light background look “fuzzy” after export—yeah, that’s often it.
Lossy formats aren’t just JPEG anymore
Modern formats can do lossy too:
- WebP supports lossy and lossless
- AVIF supports lossy and lossless
Browser support for WebP is excellent, and AVIF is strong in modern browsers as well. (caniuse.com / caniuse.com)
What “lossless” actually does (and why it can still be huge)
Lossless compression is more like folding your clothes neatly. Same clothes, less space.
It looks for patterns and repetition in pixel data and stores them efficiently.
PNG: the lossless workhorse (especially for screenshots)
PNG is lossless, supports transparency, and tends to be fantastic for:
- screenshots
- line art
- UI exports
- logos
But PNG can get heavy fast with photos, because photos are basically anti-patterns: tons of tiny variations, gradients, and noise.
That’s why “PNG is higher quality” is only half true. Yes, it preserves every pixel. No, it’s not always the right tool.
Lossless can still save space—just not always as much as you want
Lossless compression can reduce size a bit, sometimes a lot (especially with flat colors). It just can’t perform miracles on a noisy, high-detail photograph the way lossy can.
So if you’re trying to shrink a photo from 6MB to 250KB, lossless alone usually won’t get you there.
A quick visual guide: where artifacts show up first
If you only remember one thing, remember this: lossy artifacts are shy at first, then suddenly obvious.
They tend to appear earliest in:
- smooth gradients (skies, studio backdrops)
- fine repeating textures (fabric, hair, grass)
- sharp edges next to contrast (text, UI, product shots on white)
The most common mistake: compressing without resizing first
Between you and me, I see this constantly: someone compresses a 6000px image until it looks rough… when all they really needed was a 2000px delivery file.
Resize first, then compress.
- Use Resize Image to set sane dimensions
- Then use Compress Image to reduce bytes
That order tends to preserve quality because you’re not forcing compression to do the job resizing should’ve done.
Lossy vs lossless: what to use, when (a decision table that doesn’t overcomplicate it)
| What you’re working on | What people will notice | Best default | Why |
|---|---|---|---|
| Portraits / weddings / events | Skin, hair, gradients | Lossy (WebP/JPG) | Photos tolerate lossy well if you don’t overdo it |
| Product photos | Edges, subtle shadows | Lossy (WebP/JPG) | Smaller pages, faster loads; keep an eye on banding |
| Screenshots with text | Text edges | Lossless (PNG) | Keeps crisp text and UI lines |
| Logos / icons | Clean edges + transparency | Lossless (PNG) | Avoids edge shimmer and ugly halos |
| Images you’ll edit repeatedly | Re-export quality | Lossless for working files | Prevents cumulative damage |
| Social media exports | Speed + “good enough” | Lossy | Platforms recompress anyway—start clean, not massive |
If you need to switch formats quickly:
- Convert to PNG when you need transparency or crisp edges: JPG to PNG
- Convert a heavy PNG photo to something sane: PNG to JPG
- Use WebP as a modern web default: Image to WebP or JPG to WebP / PNG to WebP
The “quality slider” isn’t a morality test
I mean this kindly: chasing a perfect number like “JPEG quality 80” is how people waste afternoons.
What matters more is:
- the content (portraits vs architecture vs text)
- the display size (full-screen hero vs thumbnail)
- the viewing conditions (mobile on the go vs print review)
If you want a practical approach that works without drama:
- Export one image at your target size.
- Compress it with Compress Image.
- Compare at 100% zoom.
- Stop when you first notice something you don’t like, then nudge back.
That’s it. No spreadsheets required.
Why re-saving a JPEG hurts (and how to avoid the “death by a thousand exports”)
Lossy compression damage is cumulative. Each time you re-save a JPEG (or other lossy format), you’re compressing an already simplified version.
So if your workflow looks like:
- export JPG
- edit JPG
- export JPG again
- repeat…
…you’re basically photocopying a photocopy.
A calmer workflow:
- Keep a master (RAW/TIFF/PSD, or at least a high-quality original)
- Do edits on the master
- Export delivery versions fresh each time
For web teams, the equivalent is: don’t keep recompressing the same “optimized” image. Keep a source asset somewhere safe.
A simple File Gulp workflow (good for photographers and devs)
If you’re trying to get images ready for real-world use—client delivery, portfolio updates, product pages—this order stays reliable:
1) Resize to the real display size
Use Resize Image.
If you’re unsure, pick a “safe web large” size (like 2000–2400px wide for big photos) and adjust later.
2) Choose the right format
- For web photos: Image to WebP is a great default
- For compatibility or specific systems: Image to JPG
- For graphics and transparency: Image to PNG
3) Compress to reduce load time or download size
Use Compress Image and spot-check.
4) Remove metadata if the images will be shared publicly
Camera metadata can include GPS coordinates and device info. If that feels even a little uncomfortable, trust that instinct.
Web dev note: compression is only half the win
Compression helps. Serving the right image helps even more.
If your site shows a 1200px image, don’t ship a 3000px asset and hope compression saves you. Pair compression with responsive delivery (srcset, <picture>, or your framework’s image pipeline).
MDN’s responsive images guide is worth bookmarking. (developer.mozilla.org)
Quick takeaways (the sticky notes version)
- Lossy removes data to get much smaller files. Best for photos.
- Lossless keeps every pixel identical. Best for screenshots, logos, repeated edits.
- Resize first, then compress. It preserves quality and saves more bytes.
- Don’t recompress the same lossy file over and over—export from a master.
- If you’re publishing images publicly, metadata is part of the file. Clean it when it matters.
