Lossy throws away data your eyes won't miss. Lossless keeps everything but can't shrink as far. Knowing which to use where saves bandwidth without destroying quality.
Every image you see on the web has been compressed. The original camera file or design export was too large to serve efficiently, so something was thrown away or rearranged to make the file smaller. The question is what was thrown away — and whether you can tell.
Lossy compression removes data permanently. Lossless compression rearranges data so it takes less space but can be perfectly reconstructed. Both reduce file sizes. They do it in fundamentally different ways, and choosing the wrong one for a given image either wastes bandwidth or destroys quality. Here's how each works, with real numbers.
How lossy compression works
Lossy compression exploits the limits of human vision. Your eyes are more sensitive to brightness changes than to colour changes. They're more sensitive to low-frequency patterns (gradual gradients) than to high-frequency patterns (fine detail, sharp edges). Lossy encoders lean on these perceptual gaps to discard information you're unlikely to notice.
JPEG uses the Discrete Cosine Transform (DCT) to convert 8x8 pixel blocks from spatial data into frequency data. High-frequency components — the fine detail — are quantized more aggressively (made less precise or zeroed out entirely). The quantization table is controlled by the quality setting. At quality 90, quantization is light and detail is largely preserved. At quality 30, most high-frequency data is gone and you're looking at a smeared approximation of the original.
WebP lossy uses a similar approach with prediction-based encoding: each block is predicted from its neighbours, and only the prediction errors are encoded. Better predictions mean smaller errors, which means smaller files. AVIF goes further with more sophisticated prediction models from the AV1 video codec, achieving better compression ratios at the same visual quality.
The key fact: lossy compression is irreversible. Once the data is quantized, the original information is gone. Saving a lossy file, editing it, and saving again (re-compression) degrades quality further each time — a process called generation loss. This is why source files should always be kept in a lossless or raw format, with lossy exports generated as a final step.
How lossless compression works
Lossless compression doesn't discard anything. Instead, it finds redundancy in the data and encodes it more efficiently. PNG, the most common lossless web format, uses two stages:
Filtering: Each row of pixels is compared to the row above it (or other nearby pixels), and the differences are stored instead of the absolute values. In a photograph of a blue sky, adjacent pixels are nearly identical — the differences are tiny numbers, mostly zeros, which compress better than the raw pixel values.
DEFLATE compression: The filtered data is compressed with the DEFLATE algorithm (the same one behind gzip and zip), which finds repeated byte patterns and replaces them with shorter references. A row of 200 identical blue pixels becomes something like "blue pixel, repeat 199 times" instead of listing each one.
WebP lossless and AVIF lossless use more advanced prediction and entropy coding, achieving 25-35% smaller files than PNG for the same pixel-perfect output.
The guarantee: decompress a lossless file and you get back exactly the original pixel data, bit for bit. No quality loss. No generation loss on re-save. The tradeoff is that lossless files are typically 2-10x larger than lossy files for the same image, because there's a floor on how far you can compress without discarding information.
Real file size comparisons
Take a typical 1920x1080 photograph (uncompressed: ~6MB as 24-bit RGB):
Format Quality File size Reduction
------------------------------------------------------
PNG (lossless) 100% ~2.5 MB 58%
WebP lossless 100% ~1.8 MB 70%
JPEG q90 ~400 KB 93%
JPEG q80 ~250 KB 96%
JPEG q60 ~150 KB 97%
WebP lossy q80 ~180 KB 97%
AVIF q80 ~120 KB 98%Now take a 1920x1080 screenshot of a code editor (lots of flat colour, sharp text, few gradients):
Format Quality File size Reduction
------------------------------------------------------
PNG (lossless) 100% ~350 KB 94%
WebP lossless 100% ~220 KB 96%
JPEG q90 ~280 KB 95%
JPEG q80 ~180 KB 97%
WebP lossy q80 ~120 KB 98%Notice how the gap between lossy and lossless is much smaller for the screenshot. Screenshots have large areas of identical pixels that compress extremely well even losslessly. Photographs have complex, non-repeating pixel patterns that lossless compression can't reduce much — lossy is where the big gains are. Try both approaches on your own images with an image compressor and compare the output sizes.
The "quality 80" myth
You'll find "always use quality 80" repeated everywhere as the universal sweet spot for lossy compression. It isn't. Quality 80 in JPEG means something different from quality 80 in WebP, which means something different from quality 80 in AVIF. The scales aren't standardized across formats.
Even within a single format, the optimal quality setting depends on the image content. A photograph with lots of fine detail (foliage, fabric texture, hair) shows compression artifacts earlier than a photograph of a plain wall. Quality 80 might be perfect for one and noticeably degraded for the other.
The practical approach: start at quality 85 for JPEG, 80 for WebP, 70 for AVIF (which achieves similar visual quality at lower numeric settings). Then look at the output. If you can't see artifacts at 100% zoom on the type of display your users have, you're fine. If you can, bump the quality up. If the file size is still too large, bump it down and accept the tradeoff. There's no universal number — there's a per-image, per-format sweet spot that depends on content.
When lossy wins
Photographs. Always. JPEG, WebP lossy, or AVIF at appropriate quality. The perceptual complexity of photographs means lossless files are enormous while lossy files can discard substantial data without visible degradation. A hero image on a landing page should be lossy-compressed to the smallest size that looks acceptable on the target display density.
Thumbnails and previews. Small images at low display sizes hide compression artifacts. You can push quality lower than you'd think — quality 60-70 at thumbnail size is often indistinguishable from quality 90.
Background images and decorative elements. Users aren't studying these closely. Aggressive compression is fine.
When lossless wins
Screenshots and UI assets. Sharp text and clean edges show JPEG artifacts immediately — blurring around letterforms, ringing around high-contrast borders. PNG or WebP lossless preserves every pixel. Use an image converter to switch between formats while maintaining lossless quality.
Sprites and game art with pixel-level precision. If individual pixels matter (pixel art, sprite sheets, QR codes), lossy compression will corrupt them. Lossless only.
Source files and archives. Any image you might edit later should be stored losslessly. Edit a JPEG and re-save it 5 times and the generation loss becomes visible. Edit a PNG 50 times and it's still pixel-perfect.
Diagrams, charts, and illustrations. Images with flat colours, sharp lines, and text compress extremely well with lossless (PNG often produces small files for these) and show artifacts conspicuously with lossy. For vector-based diagrams, SVG — run through an SVG optimizer — is typically the best choice of all: resolution-independent and usually smaller than any raster format.
The decision in practice
Photograph or photographic texture: lossy (AVIF > WebP > JPEG). Screenshot, UI, text-heavy, or pixel-precise: lossless (WebP > PNG). Vector diagram or icon: SVG. Source file you'll edit: lossless always, export to lossy as the last step.
Compression isn't a quality slider with "more" and "less." It's a choice between two fundamentally different strategies, and the right one depends on what's in the image and what you need to preserve. Get the category right, and the quality number barely matters.
← All articles