Lossless vs lossy compression: when each one is worth using
Lossless keeps every pixel intact. Lossy throws some away. Knowing when to use each one can cut your storage bill in half without touching perceived quality.
Use lossless compression (PNG, WebP lossless) for source files, logos, icons, and screenshots. Use lossy compression (JPEG, WebP lossy, AVIF) for photographs and any continuous-tone image going to end users.
The core difference
Compression forces one decision: can I reconstruct this exactly, or is close enough good enough?
Lossless compression removes redundancy without discarding data. Run-length encoding, Huffman coding, LZ-based algorithms. Every pixel survives the round trip. PNG and WebP lossless both work this way. You can decompress and recompress indefinitely without degradation.
Lossy compression goes further. It models how human vision works, exploiting lower sensitivity to high-frequency detail in flat color regions and lower sensitivity to chroma than luma, discards what it predicts you won't notice, and packs what remains. JPEG, WebP lossy, AVIF, and HEIC all do this. What's discarded is gone permanently.
Everything else about format selection follows from whether the discard is acceptable.
When lossless is the right call
The clearest case is source files. If you're storing the master copy of an asset, you want lossless. Compress it lossy once and every subsequent export starts from a degraded baseline. Re-exporting at higher quality doesn't recover what's already gone.
Logos and icons are another obvious fit. These files typically have flat color regions, sharp geometric edges, and text. Lossy artifacts on hard edges show up as blur or fringing, which reads wrong on a 2x display at small sizes. PNG handles this cleanly because the color information is exact.
Screenshots follow the same logic. Pixel-accurate UI captures contain hard edges and text subpixel rendering that JPEG degrades visibly at virtually any quality setting. I've seen designers send compressed JPEG screenshots in bug reports where the artifact on the button edge was itself the JPEG, not the product. This comes up in at least a third of the design-QA handoffs I've reviewed.
There's also a practical case for lossless in automated pipelines. When you're running color correction, masking, or compositing programmatically, lossless intermediates prevent artifact accumulation across steps.
When lossy is the right call
Photographs. Any image with continuous tone, gradients, and complex texture is a candidate for lossy compression. PNG at its maximum compression level can still be 5-10x larger than an equivalent JPEG at quality 80 for photographic content in my testing across hundreds of audits; that size premium is the cost of exactness, and for most delivery contexts it's a cost you shouldn't pay. A high-quality JPEG at quality 85 at roughly 1/10th the size of a lossless PNG will be visually indistinguishable to most people in most contexts.
A 4000x3000 RGB image uncompressed is 36 MB. PNG might get that down to 12 MB on a complex photo. JPEG at quality 85 will often land at 2-4 MB. AVIF at comparable quality runs smaller still, often 1-2 MB, because its codec models spatial and frequency data more efficiently than JPEG does.
For web delivery, lossy is almost always the answer for photographic content. Images dominate page weight on every e-commerce site I audit, and the correlation between image weight reduction and LCP improvement is consistent enough that it's usually my first recommendation.
The key variable is quality setting. Most codecs use a 0-100 scale, but the relationship between the number and output quality is not linear. JPEG quality 90 and quality 85 often look identical at typical web display sizes but differ meaningfully in file size. In my testing, quality 75-85 is where most photographic content stays visually clean.
WebP lossy merits a direct comparison with JPEG. At equivalent visual quality, WebP consistently produces files 25-35% smaller than JPEG in my testing across hundreds of audits running side-by-side comparisons. For a large asset library, that's a compounding savings on storage and egress that justifies the pipeline change on its own.
Format comparison
| Format | Mode | Best for | Typical savings vs PNG |
|---|---|---|---|
| PNG | Lossless | Logos, icons, screenshots, source files | Baseline |
| JPEG | Lossy | Photographs, product shots | 60-80% smaller |
| WebP | Both | Web delivery, anything replacing JPEG/PNG | 25-35% over JPEG (lossy) |
| AVIF | Both | High-compression web delivery | 40-50% over JPEG (lossy) |
AVIF browser support is above 93% globally (Can I Use, 2025).
My hot take: skip AVIF until you're already on WebP. I tell most clients this directly. The jump from JPEG to WebP is where the actual LCP gains happen: consistent across audits, measurable in Lighthouse, worth the pipeline change. AVIF gets you another 15-20% from there, which matters at scale, but you're also taking on codec complexity and a longer encoding pipeline for a marginal gain on top of a gain you haven't captured yet. Lock in the WebP win first, then revisit AVIF once image weight is no longer the top-line problem.
The recompression trap
Re-encoding lossy files wrecks asset pipelines.
If you export a JPEG, upload it, and your storage system re-encodes it at upload time, you've run lossy compression twice. Each pass introduces new artifacts on top of the previous ones. I've opened assets in Lighthouse that have clearly gone through three or four encode cycles; the blocking artifacts are visible even at high quality settings. The fix is straightforward: store originals lossless, derive delivery copies from that source, never re-encode a lossy file. Pixel Wand handles this by storing the original upload as-is and generating thumbnails and delivery variants from that source, so re-encoding from a compressed derivative never happens.
Matching format to use case
- Source file or intermediate that will be edited or re-exported: use lossless.
- Contains text, hard edges, or flat color (logos, icons, screenshots): use lossless (PNG or WebP lossless).
- Photograph or complex texture going directly to end users: use lossy. Start at quality 80-85 and validate visually at the intended display size. Drop quality until you see artifacts, then go back one step.
- File size is the primary concern and AVIF support is confirmed: use AVIF, but only after you've already moved delivery to WebP. The one case where going straight to AVIF makes sense is a greenfield pipeline with no legacy browser constraints and a team that can monitor encode times. Most sites aren't there.
- Serving a mixed browser environment: WebP with a JPEG fallback covers 97%+ of users.
Concrete action: audit the format mix in your current asset library. If you're storing photographs as PNG, you're paying for precision you're not using. Convert delivery copies to WebP lossy at quality 82 and measure the size difference. For most photo libraries, the reduction justifies the pipeline change immediately.
If you're managing a large library and want automatic format optimization on upload, Pixel Wand handles variant generation and storage so you don't have to wire it up yourself.