Lossy vs Lossless Compression: The Difference

Every JPG, WebP, AVIF, or PNG file on your computer was shrunk by a compression algorithm before it was saved. Two families of algorithms do that shrinking, and they make very different promises about what happens to your pixels. Pick the wrong one for the wrong image and you either ship a 4 MB hero banner that tanks your Largest Contentful Paint, or you save a photograph as PNG and wonder why your photo blog is suddenly 12× heavier than it needs to be.

This guide explains what lossy and lossless compression actually do, why the same word ("compression") covers two opposite goals, and when you should care which one your tool is using. For the format-by-format decision matrix, see our companion piece onJPG vs PNG vs WebP vs AVIF— this post teaches the concept, that one teaches the buy-decision.

How lossy compression works

Lossy compression throws away information it thinks you will not notice. The classic example isJPEG: it splits the image into 8×8 blocks, runs a discrete cosine transform on each block, and then quantizes the resulting coefficients — a fancy way of saying "round these numbers to a coarser grid." Rounding is destructive: the original value is gone. What saves you is that high-frequency coefficients (tiny color shifts between neighboring pixels) get rounded more aggressively than low-frequency ones (broad shapes), and your visual system is much more sensitive to the latter.

WebP and AVIF are also lossy by default — but they layer that same trick on top of better predictors. WebP uses a VP8-style intra predictor to guess each block from its neighbors before encoding the small residual. AVIF goes further with intra frames from AV1, so it gets JPG-quality images at noticeably smaller files. Both formats also tune their quantization tables against perceptual models (often SSIMULACRA2 or Butteraugli), so the "quality slider" actually maps to "human-perceived quality," not just signal-to-noise.

The most important caveat with lossy is the cascading-recompress trap: every time you re-encode a JPEG, you quantize again and lose another generation of detail. Saving a quality-90 JPG as quality-90 ten times does not give you the same file as saving it once — it gives you a softer image. Always keep a master original and export from it.

How lossless compression works

Lossless compression keeps every single pixel identical. It cannot invent smaller files than the original data allows, so it works by removing redundancy instead of discarding information. PNG uses a row-by-row filter (None, Sub, Up, Average, Paeth) that predicts each pixel from its neighbors and stores only the small difference, then runsdeflate (the same algorithm inside ZIP and gzip) on top of those differences. A flat-color UI screenshot compresses to a tiny fraction of its size because every row predicts the next one perfectly.

GIF uses the older LZW dictionary coder, which is why it tops out at a 256-color palette and why it is now mostly a historical curiosity for static images. WebPand AVIF can both switch into lossless mode as well — WebP lossless often beats PNG by 20–30% on UI assets, and AVIF lossless goes further still. The tradeoff is encode speed: lossless WebP/AVIF encode much more slowly than their lossy counterparts, which is why most pipelines only use them for assets that have already been curated.

The defining property of lossless is that decoding always returns the original bits. You can save a PNG a hundred times and the file will be byte-for-byte equivalent to the first save. That guarantee is why logos, icons, and source-of-truth design assets stay in lossless formats even though they look "boring" on a byte-budget chart.

When to pick which

Use the photo rule: anything captured by a camera (or anything with continuous tone, gradients, and noise) should default to lossy unless you have a specific reason not to. JPG at quality 80–85, WebP at 75–85, or AVIF at 50–60 are all "visually indistinguishable from the original" for most monitors. The 5–10× file-size savings are not negotiable on a fast web page.

Use the graphic rule: anything with flat color, hard edges, text, or transparency (logos, icons, diagrams, screenshots) should default to lossless. The artifacts of lossy compression — ringing around text, color bleed across transparency edges, banding in gradients — show up immediately on those images. PNG or lossless WebP will outcompress JPG on these assets anyway.

The one exception is the "almost-lossless" middle ground: a high-quality lossy encode (quality ≥ 90) is often indistinguishable from the original even for graphics, and can save 40–60% versus PNG. That is the right knob to turn when the master is in PNG but you need a smaller deliverable for the web. For a side-by-side comparison of how the formats actually perform on real images, readJPG vs PNG vs WebP vs AVIF.

How ImagElite handles each

ImagElite's image compressorexposes both modes through one slider. When you drag the quality slider for a JPG output, you are driving the lossy encoder directly — lower quality means a coarser quantization grid, smaller file, more visible artifacts at extreme zoom. When you switch the target format to PNG or to the lossless variants of WebP and AVIF, the slider disappears and the tool falls back to a pure redundancy-removal pipeline that keeps every pixel identical to your upload.

Because everything runs locally in your browser, you can A/B test the two modes on the same image without re-uploading anything. Drop in a screenshot, then a phone photo, and watch how the size delta between lossy and lossless output flips completely between the two — that gap is the redundancy that lossless cannot compress further. It is also the gap that lossy is willing to throw away to keep your page fast.