Lossy vs. Lossless Compression: What Actually Happens When You Shrink an Image

"Compress this image" gets treated as a single operation with a quality dial, but lossy and lossless compression are really two different promises about what happens to your data. One promises a smaller file and accepts that some detail is gone for good. The other promises the exact original pixels back, every time, and settles for a more modest size reduction in exchange.

Knowing which promise you're making — usually decided by the file format you save into, not a checkbox — is the difference between a compressed photo that looks fine and a compressed screenshot that looks noticeably worse than the original.

JPEG-style lossy compression works by identifying detail human vision is comparatively bad at noticing — subtle color shifts, high-frequency texture — and discarding it, permanently. That data doesn't exist anymore once the file is saved; there's no setting that brings it back on a later re-save.

At moderate compression this is genuinely invisible. Push it too far, though, and the discarding becomes visible as its own kind of artifact: blocky squares around sharp edges, and banding where a smooth gradient — a sunset sky, a shadow — should be continuous but instead steps between visible bands of color.

“Lossy compression doesn't make the file smaller by being clever — it makes it smaller by leaving detail behind.”

Lossless compression, the kind PNG uses, never discards a single pixel value. It finds smarter, more efficient ways to encode the exact same data — exploiting repetition and patterns the same way a zip file shrinks a text document without changing a single letter inside it. Decompress it and you get back pixel-for-pixel the same image you started with.

This is why PNG is the standard choice for screenshots, logos, and diagrams: large flat-color regions and sharp text edges compress extremely efficiently even losslessly, and there's zero risk of the blocky artifacting a photo-oriented lossy format would introduce around crisp text.

Run a photo and a screenshot through the same lossy compressor and the outcomes diverge sharply, for a structural reason, not a bug.

• A photo has enormous amounts of subtle, redundant micro-detail across its whole surface — exactly the kind of detail lossy compression is designed to discard first, with minimal visible cost.
• A screenshot or logo has few distinct colors and sharp, high-contrast edges (text, UI lines) — exactly where lossy artifacting is most visible, because there's no busy detail to hide it in.

A 4000×3000 photo destined for an 800px-wide blog embed benefits more from being resized down first than from cranking the compression quality down. Compression re-encodes the pixels you already have; resizing reduces how many pixels there are to store in the first place — a lever compression alone can't pull.

Open Tools Library's Image Compressor shows a live before/after size comparison so the trade-off is visible before you commit, the Image Format Converter switches cleanly between JPG, PNG, and WEBP, and the Image Resizer handles the pixel-dimension lever separately. All three run entirely in your browser — nothing you upload leaves the tab.