Lossy vs Lossless Compression: How Image File Size Actually Shrinks

Quick answer: Lossless compression (PNG's default behavior) re-encodes an image's exact pixel data more efficiently and loses nothing when decompressed. Lossy compression (JPG's whole design) permanently discards detail a viewer is statistically unlikely to notice, which is why it achieves much smaller files. Neither is "better" outright - the right choice depends on whether the image is a photo (lossy wins) or has sharp edges and flat color like a screenshot or logo (lossless wins).

"Compress this image" can mean two very different operations depending on the format involved, and they trade off completely different things. One makes a file smaller by deciding you won't miss certain detail. The other makes it smaller without deciding anything at all.

What "lossless" and "lossy" actually mean

Lossless compression re-encodes the exact same pixel data in fewer bytes, with zero information discarded; decompressing it returns the original image bit for bit. Lossy compression permanently discards some of the original data, chosen because a viewer is statistically unlikely to notice it's gone, and can never fully recover the original once that data is thrown away. Both are legitimately "compression," they just define the word differently.

Lossless: smaller file, identical pixels

Lossless compression (PNG's default behavior) finds redundancy in the image data and encodes it more efficiently - a run of a thousand identical white pixels doesn't need to be stored a thousand times, for instance. Decompress it and you get back the exact original pixel values, bit for bit. Nothing about the image was decided to be unimportant; the file is just a more efficient encoding of the same information.

How lossless algorithms find that redundancy

PNG's lossless step is built on DEFLATE, the same general-purpose compression family used by ZIP: it looks for repeated byte sequences and encodes them as short references instead of storing them again, then runs a final entropy-coding pass on what's left. None of that touches a single pixel's actual color value, it's purely a more efficient way to write down the same data, which is why decompression is exact rather than approximate.

This is why PNG is the right call for screenshots, logos, and line art: large flat areas of identical color compress extremely well losslessly, and there's no quality to lose in the first place since nothing gets discarded.

Lossy: smaller file, some detail gone on purpose

Lossy compression (JPG's whole design) takes a different approach: it identifies detail a viewer is statistically unlikely to notice, subtle color gradients, high-frequency texture, and discards it rather than encoding it. This is why a JPG can be a fraction of an equivalent PNG's size: it's not encoding the same information more efficiently, it's encoding less information to begin with.

How JPG decides what to throw away

JPG's encoder leans on two properties of human vision: we notice changes in brightness far more than changes in color, and we notice sharp detail far more than smooth gradients. It uses that to subsample color information at lower resolution than brightness, then breaks the image into small blocks and represents each one as a sum of frequency patterns, discarding the higher-frequency (finer-detail) patterns more aggressively as the quality setting drops. The result is smaller files that still look right to a human eye, at the cost of detail a computer comparing pixel values could absolutely detect.

This works well for photographs, where that discarded detail genuinely is hard to spot, and works badly for sharp-edged graphics like text or line art, where the same discarding shows up as visible blur or ringing around edges.

Where WebP fits in

WebP supports both modes in one format, lossy for photos, lossless for graphics, and its lossy mode in particular tends to beat JPG at the same visual quality, which is why it's become a common target for a general-purpose shrink.

Lossy WebP vs lossless WebP

Lossy WebP uses a more modern prediction scheme than JPG's older block-based approach, which is most of why it can hit a smaller file size at a visually similar quality level. Lossless WebP competes directly with PNG the same way, same zero-information-loss guarantee, generally tighter encoding. The tradeoff isn't quality at all here, it's compatibility: some older software and a handful of print workflows still expect JPG or PNG specifically.

Image Compress handles JPG, PNG, and WebP, picking sensible settings for each rather than treating every format the same way.

Real-world size differences

The gap between lossy and lossless isn't subtle. A high-resolution photo saved as lossless PNG commonly lands in the tens of megabytes, since photographic noise gives a lossless encoder very little redundancy to exploit. The same photo saved as JPG or lossy WebP at a reasonable quality setting typically comes in at a fraction of that size, often under a tenth, because the encoder is actively throwing away the noise and fine gradients a lossless format has to preserve. Flip the image type around and the gap shrinks or reverses: a flat-color screenshot or app icon saved as PNG is often already small, and running it through lossy compression buys little extra size reduction while introducing visible artifacts it didn't have before.

Common mistakes worth avoiding

Re-saving a JPG over and over. Every save re-runs lossy compression on whatever's currently in the file, so repeated edit-and-save cycles compound the quality loss even if each individual save looks fine. Keep an uncompressed or lossless master and export a fresh JPG from it each time, rather than editing the JPG itself repeatedly.

Using PNG for photographs. It's not wrong exactly, lossless is lossless, but it throws away the entire size advantage lossy compression exists to provide, often for a 5-10x larger file with no visible benefit on a photo.

Using JPG for text-heavy screenshots or diagrams. The same discarding that's invisible on a photo shows up immediately as blur and ringing around sharp text edges and hard color boundaries, exactly the content type lossy compression handles worst.

Choosing the right one for the image you actually have

The honest rule of thumb: if the image is a photo, lossy compression is nearly free quality-wise and buys a real size reduction. If it's a screenshot, icon, or anything with sharp edges and flat color, lossless keeps it crisp and often compresses close to as well anyway, since there's less random photographic noise fighting the compressor. Image Convert makes it easy to try a photo as WebP or a graphic as PNG and compare the result directly rather than guessing.

The short version

Lossless compression re-encodes the same pixels more efficiently and loses nothing. Lossy compression gets smaller by deciding some detail isn't worth keeping. Neither one is "better" in the abstract, which one actually helps depends entirely on whether the image is the kind of thing where lost detail is invisible (a photo) or immediately obvious (anything with hard edges and flat color). Image Compress and Image Convert both run the comparison for you rather than asking you to guess ahead of time.