A designer drops a 4 MB hero image into your pull request, the page feels sluggish on a mobile device, and Lighthouse flags the image as a major opportunity. The right response isn't to compress everything as aggressively as possible. Lossy vs lossless compression is a workflow decision, based on the asset, the delivery format, the audience's devices, and the cost of decoding it in the browser.
Author: PageSpeed Plus staff
Reading time: 8 minutes
Meta title: Lossy vs Lossless Compression Guide for Web Images
Meta description: Learn when to use lossy or lossless compression, how AVIF and WebP affect decoding, and how to optimize images for real-world web performance.
Use this table of contents to jump to a specific decision:
A product photo loads quickly, yet a small screenshot looks blurry after export. That difference comes from the compression method, the asset's purpose, and the browser work required to decode it. Lossy vs lossless compression is a workflow decision, not merely a format choice. The correct choice depends on the asset and its job, while the final test is its effect on visual clarity and Core Web Vitals.
Lossy compression removes information permanently. Codecs discard details viewers are less likely to notice, then encode the remaining data more efficiently. Use it as the default for photographs, hero images, backgrounds, and gallery assets delivered over a network. Smaller files usually reduce transfer time, but complex codecs can still add decode work on the client device.
Lossless compression preserves the original data exactly. Decompression reconstructs the same image, audio stream, or document. Choose it for screenshots, interface graphics, logos, text-heavy images, archival masters, and assets that must survive repeated editing without accumulating artifacts. The larger payload can delay delivery, so reserve it for cases where exact pixels matter.
| Decision factor | Lossy compression | Lossless compression |
|---|---|---|
| Data integrity | Some information is discarded | Every bit is preserved |
| Best image type | Photography and complex visuals | Text, UI, logos, and screenshots |
| Primary benefit | Much smaller delivery files | Exact reconstruction |
| Main risk | Artifacts and irreversible quality loss | Larger payloads and slower delivery |
| Practical default | Public web delivery | Source, archive, and precision assets |
Practical rule: Keep a high-fidelity master, then create a delivery version that matches the asset's visual importance, rendered size, and users' devices.
Compression artifacts include ringing, blockiness, blurred edges, and mosquito noise around text. If a JPEG was compressed too aggressively, this guide to how to fix JPEG compression artifacts can help identify the cause. Re-export from the original source instead of repeatedly compressing the damaged file.
Judge the result at its actual display size. A photograph may tolerate lossy compression, while a small product label or screenshot can become unreadable quickly. Select the version that preserves the information users need, transfers efficiently, and decodes within the performance budget.
A browser does not receive an abstract “quality setting.” It receives encoded bytes, then spends CPU time decoding them into pixels. That makes compression a workflow decision: choose the smallest asset that still preserves the information users need, then verify its transfer and decode cost on the target device.
JPEG-style lossy compression divides an image into 8×8 pixel blocks. The Discrete Cosine Transform, or DCT, converts each block from individual pixel values into frequency information. Quantization then reduces precision, especially where visual changes are less noticeable. The result is a smaller file, but some information cannot be recovered.
Quantization controls the tradeoff. More aggressive reduction removes more coefficient detail, increases artifact risk, and usually lowers transfer cost. JPEG quality controls commonly use a 1 to 100 scale, but encoder behavior varies, so the number is not a universal measure of visual quality. This technical explanation of image compression explains why identical settings can produce different results.
Lossless codecs work differently. They detect repeated patterns, predict values from neighboring data, and assign shorter representations to frequent symbols. PNG filters pixel data before back-end compression, while FLAC uses predictive and coding techniques without changing the decoded waveform.
Lossless compression has a practical ceiling. A 2022 IEEE conference paper reports a typical 2× compression ratio on scientific data, while a 2025 survey places the maximum achievable lossless reduction just above 2x. The survey reports that lossy compression can reach up to 8x, depending on the source and acceptable quality tradeoff. The IEEE publication provides technical context for these limits.
Use exact reconstruction for software packages, text, structured data, and archival masters. For public media delivery, test whether discarded detail affects readability or brand-critical features, then measure transfer size and decode timing. A smaller file can improve loading, while expensive decoding can still affect responsiveness on slower devices.
When a regression appears, inspect the request waterfall and response behavior in a HAR file, then compare transfer size, dimensions, and decode timing on the target device.
Compression is a workflow decision, not a permanent format choice. Choose the delivery codec for the viewer, then preserve a source that can survive the next edit, export, or inspection. The right choice also includes decode cost, because a smaller payload can still hurt Largest Contentful Paint or responsiveness if the browser spends too long decoding it.
| Media type | Lossy default | Lossless default | Typical lossless ratio | Best use case |
|---|---|---|---|---|
| Images | JPEG, WebP, or AVIF | PNG or lossless WebP | Near 2x on many scientific datasets, as noted earlier | JPEG for broad compatibility, WebP for fast general delivery, AVIF for stronger photographic reduction, PNG or lossless WebP for text, UI, and diagrams |
| Audio | MP3 or AAC | FLAC or WAV | FLAC commonly reaches 50 to 70 percent of the original size while preserving an identical copy, FLAC reference | MP3 or AAC for streaming, FLAC for masters and archives, WAV when an uncompressed working file is required |
| Video | H.264, HEVC, or AV1 | Codec-specific lossless mode | Varies by source | H.264 for compatibility, HEVC or AV1 for supported delivery targets, AV1 lossless modes for production intermediates where the encoder and workflow support them |
For images, select the codec by asset type and device cost. Use AVIF for photographic hero images when byte savings justify its decode work. Use WebP when a lighter decode path matters more. Keep PNG for screenshots, diagrams, and interface assets with sharp edges or readable text. Test rendered dimensions, transfer size, and decode timing rather than judging formats by file size alone.
Audio has a clearer preservation boundary. Streaming can use MP3 or AAC because delivery efficiency matters. Keep the studio master lossless, and use FLAC when you need an exact copy in less storage than WAV.
Video requires the same separation. H.264, HEVC, and AV1 target delivery, while codec-specific lossless modes can protect editing intermediates. Start every export from a high-fidelity source, then test playback and decode behavior on the target device.
Choose compression around the next operation, not just the current download. A lossy public file can improve loading, but retain a lossless master for later editing, inspection, or transformation.
A larger image payload can delay the request and transfer of the page's largest visible element, which can worsen Largest Contentful Paint. Compression also affects the browser after the bytes arrive. Decoding a complex image can consume CPU and memory, particularly on low-spec devices, so the smallest file isn't automatically the fastest experience.
AVIF usually saves more bytes than WebP for photographic content, but WebP often decodes faster. That creates a practical production rule: use AVIF where byte reduction matters most, use WebP where decode efficiency is more important, and retain a fallback for clients that don't support the preferred format.
The encoding tradeoff matters too. In one benchmark, JPEG 2000 reached 34.6 dB PSNR and 0.93 SSIM on the Lena image at 0.5 bpp, compared with JPEG at 32.5 dB PSNR and 0.89 SSIM. JPEG 2000 encoding took 0.89 seconds, compared with 0.15 seconds for JPEG, while lossless PNG delivered 1.00 SSIM but produced a larger 128 KB file. The comparative study illustrates why quality, encoding time, file size, and runtime behavior must be evaluated together.
Test on real devices and networks. A lab report can confirm that the response is smaller, but field data shows whether users experience better LCP, INP, and TTFB. For a broader video workflow, use a method to compare video quality and file size, then inspect the page's actual loading path and critical rendering path.
Don't choose one image format for an entire site. Choose it per asset category.
For photographs, AVIF is the strongest lossy starting point. A comparative analysis reports that AVIF is about 10% smaller than WebP at comparable visual quality, while both substantially outperform JPEG for photographic content. WebP remains a strong choice when browser decode speed or simpler fallback behavior matters more than maximum byte reduction. The image format comparison also reports that lossless WebP averages 1.42x smaller than JPEG and 1.70x smaller than PNG for photos, while PNG remains the most efficient lossless option for text-heavy images such as screenshots and UI assets.
Use this decision table when assigning formats:
| Asset | Recommended delivery | Why |
|---|---|---|
| Hero photograph | AVIF lossy, with WebP fallback | Maximum photographic efficiency |
| General photography | WebP lossy or AVIF | Balances bytes and decode behavior |
| Screenshot or UI text | PNG or lossless WebP | Preserves crisp edges and lettering |
| Logo with transparency | Lossless WebP or PNG | Protects transparency and contours |
| Legacy integration | JPEG or PNG fallback | Maintains broad compatibility |
WebP and AVIF can both operate in lossy or lossless modes. Browser support is reported in the mid-90% range for both formats during 2025 to 2026, so the practical problem is fallback strategy, not whether modern browsers can display them. A recent format comparison supports the hybrid approach.
Keep JPEG as a fallback when compatibility requirements demand it, but don't make it the automatic primary format for every photograph. For WordPress implementation details, see WordPress speed optimization without a plugin, then decide whether automation belongs in your publishing workflow.
Start with the original export. Resize the image to the largest display dimension your layout needs, then choose compression based on content rather than file extension. Don't convert a screenshot to aggressive lossy AVIF just because the format is modern.
A reliable workflow looks like this:
The PageSpeed Plus WordPress plugin can handle WebP and AVIF conversion, lazy loading, image compression, caching, and Brotli in one stack. That turns a repeated custom build process into a configuration task, while the PageSpeed Plus dashboard can track field metrics and scheduled tests.
For batch validation, run a bulk PageSpeed Insights test across representative templates. Check more than one page, because a format that works for a product gallery may be wrong for a documentation screenshot.
Ask three questions before exporting each asset:
Most production sites should use a hybrid stack, not a single compression policy. Preserve lossless masters, deliver lossy modern formats for photography, and measure LCP, INP, CLS, and TTFB after deployment. For continued performance work, read the Real User Monitoring guide and the third-party code impact guide.
PageSpeed Plus combines Core Web Vitals monitoring, automated scans, field data, and WordPress optimization features including image conversion, lazy loading, caching, and Brotli. Visit PageSpeed Plus to test your site, identify image bottlenecks, and verify whether your compression choices improve real user experience.