Image Compression Techniques: Lossy vs Lossless, Formats, and Web Optimization (2026)

Images account for an average of 51% of total page weight across the web (HTTP Archive, 2025). No other asset type has as much impact on page load time, and no other optimisation delivers faster results than getting image compression right. A 2 MB page full of unoptimised images can often be reduced to 500–700 KB with zero visible quality difference using the techniques in this guide.

This is the complete image compression guide for 2026: what lossy and lossless mean at the algorithm level, how each format makes its decisions, what quality settings actually do, where the format and quality interaction matters, and what specific size targets to aim for in each web image category.

1. TL;DR Decision Tree

2. Lossy Compression Explained

Lossy compression permanently removes data from an image to achieve smaller file sizes. The key insight that makes this work is that human vision is not uniformly sensitive to all types of visual information. Specifically:

• We are far more sensitive to luminance (brightness, light/dark variation) than to chrominance (colour variation)
• We are far more sensitive to low-frequency patterns (large-scale brightness gradients, main shapes) than to high-frequency detail (fine texture, sharp edges at small scales)
• We are more sensitive to spatial patterns in the centre of our field of vision than in the periphery

Lossy encoders exploit these properties by identifying the visual information we are least likely to notice and discarding it first. The result: a file that appears visually identical to the original but is 80–95% smaller when measured in bytes.

What Data Gets Discarded

In a JPEG of a landscape photograph:

• Colour channel data is typically halved in resolution before encoding even begins (chroma subsampling). You lose some colour detail, but you cannot see it because your visual system has low spatial resolution for colour.
• High-frequency texture data in each 8x8 pixel block is rounded toward zero. The fine grain in a wood texture, the subtle pores in skin, the individual leaves of a distant tree — all heavily quantised.
• Fine detail in flat-ish areas — the barely perceptible variation in a clear blue sky — is quantised aggressively, producing a perfectly smooth gradient instead of the original slight noise.

What remains: the overall shapes, the primary colour relationships, the large-scale tonal gradients that define the image composition. Your brain reconstructs the perception of detail from context.

The Artefact Problem

Lossy compression works perfectly up to a point. The failure mode occurs when the quantisation is pushed too far: the 8x8 block boundaries become visible in JPEG (blocky artefacts), or smearing/ringing occurs at edges in WebP. These artefacts are the signal that the encoder has discarded too much — the missing data is now noticeable. Getting the quality setting right means finding the point just above where artefacts appear for your specific image content.

3. Lossless Compression Explained

Lossless compression reduces file size without discarding any image data. The decompressed result is identical to the original, pixel for pixel, regardless of how many times it is saved and re-opened. This is possible because image data contains patterns and redundancies that can be stored more efficiently than a raw pixel dump.

How DEFLATE Works (PNG's Algorithm)

PNG uses a two-stage lossless algorithm:

Stage 1 — Filtering: Before compression, PNG applies a filter to each row of pixels to transform the data into a form that is more compressible. The most common filter ("Sub") stores each pixel as the difference from the pixel to its left. For an image with a smooth gradient, most pixels are very similar to their neighbours — the differences are small numbers near zero, which compress much better than the original colour values.

Stage 2 — DEFLATE: The filtered data is then compressed using DEFLATE (the same algorithm used in ZIP files), which combines LZ77 backreference matching (finds repeated sequences and replaces them with references to the first occurrence) with Huffman coding (assigns shorter binary codes to more frequent values). The result is lossless — every bit of the original can be reconstructed exactly from the compressed form.

Lossless vs Lossy: The Size Reality

The key practical rule: use lossy compression for any image with smooth colour gradients and photographic content. Use lossless compression for images with sharp edges, flat colour areas, text, logos, screenshots, and any file you will edit again. Getting this choice right often matters more than any quality setting.

4. Why Format Choice Matters More Than Quality Settings

A common misconception is that you can compensate for a suboptimal format choice by adjusting the quality setting. You cannot — format architecture determines the compression efficiency ceiling. The same image at quality 85 in JPEG vs quality 85 in WebP lossy is not the same file size. Here is the reality:

* Approximate sizes for a typical 1200x630 photograph. Actual sizes vary by image content.

The insight: WebP at quality 82 produces visually identical output to JPEG at quality 85, but at roughly 70% of the file size. You cannot reach the same combination of quality and file size using JPEG by adjusting its quality setting alone — at the file size where WebP at Q82 lands, JPEG would need to be at quality 70, which shows visible artefacts.

This is why format choice is the primary lever for image optimisation. Once you have chosen the right format, quality setting tuning is refinement. Choosing the wrong format means you are working against the format's architectural ceiling.

5. JPEG Compression Deep Dive

JPEG compression uses the Discrete Cosine Transform (DCT), a mathematical technique that converts spatial image data (pixel values at specific coordinates) into frequency domain data (how much of each spatial frequency pattern is present in each image block). This frequency representation is the key that enables efficient compression: human vision is non-uniform in its sensitivity to different spatial frequencies.

The Quantisation Table

The quality setting in JPEG encoders controls a quantisation table — a matrix of 64 values, one for each DCT coefficient position. Each DCT coefficient is divided by its corresponding quantisation value, then rounded to the nearest integer. High quantisation values produce aggressively rounded results (small integers, mostly zeros), while low values preserve precision.

At quality 95, the quantisation values for high-frequency coefficients are small (1–3), preserving most detail. At quality 60, the quantisation values for high-frequency coefficients are large (50–100+), rounding most high-frequency data to zero. The entropy coding step then achieves excellent compression on these runs of zeros.

Where JPEG Fails

The 8x8 block structure that enables JPEG's compression is also its fundamental weakness. At block boundaries, two adjacent blocks are compressed independently — if the quantisation is heavy, the reconstructed blocks may have slightly different average brightnesses or colour tints, producing a visible grid pattern. This "blocking artefact" is the characteristic failure mode of JPEG at low quality settings.

The other failure mode is ringing — high-contrast edges (text, logos, sharp transitions) produce oscillating brightness patterns around the edge. This is the mathematical consequence of representing a sharp step function (a hard edge) using a limited set of frequency components. The missing high-frequency components are what produce the clean edge; without them, you get the approximation error as visible ringing.

Progressive JPEG

Progressive JPEG encodes the image in multiple scan passes of increasing quality. The first scan transmits a low-quality preview of the entire image; subsequent scans refine it progressively. On slow connections, this means users see a blurry-but-complete image that sharpens as more data arrives — better perceived performance than the top-down line-by-line display of a standard ("sequential") JPEG. Modern browsers all support progressive JPEG, and it is the recommended encoding for web use.

6. PNG Compression Deep Dive

PNG (Portable Network Graphics) uses lossless compression throughout. It was designed in 1996 as a patent-free replacement for GIF and as a web format for images requiring transparency. Its compression is based on DEFLATE — the same algorithm used in ZIP files — applied to pixel difference data rather than raw pixel values.

Filter Types

Before DEFLATE compression is applied, PNG applies a row filter to each horizontal scanline of the image. There are five filter types (None, Sub, Up, Average, Paeth), and the encoder typically tests each and selects the one that produces the most compressible result for that specific row. The "Sub" filter stores each pixel as the difference from the previous pixel in the same row; the "Up" filter stores each pixel as the difference from the pixel directly above. For images with smooth gradients, these difference values are small numbers near zero, which compress much more efficiently than the original colour values.

Bit Depth and Colour Modes

PNG supports multiple colour modes that significantly affect file size:

• RGBA (32-bit) — full colour with alpha channel. Used for any image requiring transparency.
• RGB (24-bit) — full colour without transparency. Smaller than RGBA.
• Greyscale with alpha (16-bit) — greyscale with transparency.
• Greyscale (8-bit) — no colour information. Smallest for monochrome images.
• Indexed colour (1–8 bit) — limited palette up to 256 colours. Very small files for simple graphics. This is the same mode GIF uses.

Choosing the right colour mode for your image type can significantly reduce PNG file sizes. A greyscale screenshot saved as RGB PNG is 3× larger than necessary — all three colour channels contain identical data. Use greyscale mode for greyscale images, and indexed colour for simple graphics with few distinct colours (icons, logos with flat colour areas).

PNG Compression Level

The compression level setting in PNG (typically 0–9) controls how much effort the DEFLATE encoder expends searching for efficient patterns. Level 9 spends the most time and achieves the smallest files; level 1 is fast but produces larger files. Unlike JPEG quality, PNG compression level never affects image quality — it only affects file size and encoding time. For web use, level 6–9 is recommended. The difference between level 6 and level 9 is typically 2–5% smaller files at the cost of noticeably longer encoding time.

7. WebP: Best of Both Worlds

WebP uniquely combines lossy and lossless compression modes in a single container format. This means a single WebP pipeline can serve as a replacement for both JPEG (lossy photos) and PNG (lossless graphics with transparency), simplifying web asset management considerably.

WebP Lossy Mode (VP8)

WebP lossy uses the VP8 video codec's intra-frame compression. Like JPEG, it transforms image data into frequency domain representation — but uses a more sophisticated technique called transform coding with prediction. The encoder first predicts the content of each block from neighbouring already-encoded blocks, then applies a DCT to the difference between the prediction and the actual content. The prediction step means the residual (the difference that needs to be stored) is much smaller than the raw pixel values, enabling more efficient compression than JPEG's approach of DCT-coding raw blocks without prediction.

The result: at the same visual quality, WebP lossy files are 25–34% smaller than JPEG. The compression artefact pattern is different — WebP produces a blurring/smearing effect rather than JPEG's blocking artefact — which some images handle better and some handle worse. Test both formats on your specific images when making the choice.

WebP Lossless Mode (VP8L)

WebP lossless uses a separate algorithm — VP8L — that applies a series of transformations designed to improve compressibility before the final entropy coding step:

• Colour transform — converts the colour space to reduce correlation between channels
• Subtract green transform — removes green channel from red and blue to reduce redundancy
• Colour indexing transform — replaces similar colours with palette references for images with limited colour palettes
• Backreference matching — finds repeated pixel patterns and replaces with references, similar to LZ77
• Huffman coding — entropy coding of the final transformed data

The result: lossless WebP is approximately 26% smaller than equivalent PNG for typical web images. For images with large areas of identical colour (flat icons, simple logos), the savings are larger. For complex photographic PNG images (where most values are unique), the savings are smaller.

The WebP Quality Scale

WebP quality (0–100) is not equivalent to JPEG quality (0–100). WebP Q80 produces visual quality roughly equivalent to JPEG Q85–90. When converting from JPEG to WebP, start with WebP Q80–82 and compare visually with your JPEG source. You can often match or exceed the visual quality of JPEG Q85 at WebP Q80 while achieving a 25–34% smaller file.

8. AVIF and JPEG XL: Next-Generation Compression

Two next-generation image formats offer significantly better compression than both JPEG and WebP. Understanding their current status helps you decide whether to adopt them now or wait.

AVIF (AV1 Image Format)

AVIF is based on the AV1 video codec, developed by the Alliance for Open Media (a coalition of Google, Microsoft, Apple, Netflix, Amazon, and others). It achieves 40–50% smaller files than JPEG at equivalent visual quality — a significantly larger advantage than WebP's 25–34%.

The recommended AVIF quality range for web delivery is 50–65. This range produces visual quality equivalent to JPEG 85–90 but at file sizes 40–50% smaller. The quality scale is non-linear — AVIF quality 60 produces different visual results than JPEG quality 60.

To serve AVIF with WebP and JPEG fallbacks:

<picture>
  <source type="image/avif" srcset="image.avif">
  <source type="image/webp" srcset="image.webp">
  <img src="image.jpg" alt="Description" width="1200" height="630" loading="lazy">
</picture>

JPEG XL

JPEG XL is technically impressive: it achieves better compression than AVIF for many image types, supports lossless re-encoding of existing JPEG files (you can convert your entire JPEG archive to JPEG XL with a reversible encoding, then verify and delete the originals), supports HDR, wide gamut, animation, and progressive decoding. As of 2026, only Safari has shipped JPEG XL support — Chrome removed its experimental implementation in 2023. JPEG XL remains a format to watch but not to deploy broadly.

9. Practical Web Optimization: Size Targets

Concrete size targets give you a clear pass/fail criterion for each image type rather than optimising indefinitely. These targets are based on reasonable expectations for mobile connections and Core Web Vitals requirements:

These targets are aggressive — many sites exceed them significantly. The 500 KB total page image budget is the threshold at which LCP on a median 10 Mbps mobile connection starts to become a bottleneck. Above this threshold, image loading is likely contributing to LCP failures.

Responsive Images: Serving the Right Size

Serving a 1200px-wide image in a 400px-wide container wastes 89% of the pixel data — the browser downloads the full file and then scales it down in CSS. Responsive images via the srcset attribute serve the correct resolution:

<img
  srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
  sizes="(max-width:600px) 100vw, (max-width:900px) 80vw, 1200px"
  src="image-1200.webp"
  alt="Description"
  width="1200" height="630"
  loading="lazy"
>

A mobile user with a 390px-wide screen downloads the 400w variant; a desktop user with a 1440px screen downloads the 1200w variant. Combined with WebP conversion, responsive images can reduce image payload by 60–70% for mobile users compared to serving one large image.

10. Tools: Browser-Based vs Server-Side vs CLI

The right tool depends on your workflow, volume, and technical context:

CLI Quick Reference

For developers who want command-line tools for batch processing:

# Convert JPEG to WebP at quality 82 (cwebp)
cwebp -q 82 input.jpg -o output.webp

# Convert JPEG to AVIF (avifenc from libavif)
avifenc --quality 60 --speed 6 input.jpg output.avif

# Batch convert all JPEGs in a directory to WebP (bash)
for f in *.jpg; do cwebp -q 82 "$f" -o "${f%.jpg}.webp"; done

# Strip EXIF metadata and convert to WebP (ImageMagick)
convert input.jpg -strip -quality 82 -define webp:lossless=false output.webp

11. Core Web Vitals: How Image Compression Affects LCP

Google's Core Web Vitals include Largest Contentful Paint (LCP) — the time until the largest image or text block in the viewport becomes fully rendered. For most web pages, the LCP element is an image: a hero banner, a product photo, or a featured image. Image compression directly determines LCP performance.

The LCP Threshold

Google's thresholds for LCP are:

• Good: LCP under 2.5 seconds
• Needs improvement: 2.5–4.0 seconds
• Poor: Over 4.0 seconds

On a median mobile connection (approximately 10 Mbps download speed, 100ms RTT), a 300 KB hero image takes approximately 240 ms to download. A 150 KB WebP version of the same image takes approximately 120 ms — saving 120 ms of LCP time. Across an entire page load with multiple sequential dependencies, this is meaningful.

The LCP Image Optimisation Checklist

12. Frequently Asked Questions

Getting image compression right is one of the highest-return optimisations in web performance. The combination of choosing the right format (WebP over JPEG for web delivery), using appropriate quality settings (80–85 rather than 95+), serving correctly sized images via srcset, and lazy-loading off-screen images typically delivers a 60–80% reduction in image payload with no visible quality change. The tools to do all of this are free and run entirely in your browser — start with the compressor above.