WebP vs JPEG Compression: A Data-Driven Comparison

The Headline Numbers: What the Benchmarks Say

The figure most frequently cited comes from Google's own benchmarks published when WebP was introduced in 2010, subsequently confirmed by independent studies: at equivalent visual quality, WebP produces files 25–35% smaller than JPEG. This gain applies to lossy encoding, which is the mode used for photographic content on the web.

In lossless mode, WebP outperforms PNG by 25–34% depending on image type; but that comparison sits outside the JPEG scope, as JPEG is an exclusively lossy format.

These figures are averages. Real-world results vary by content type, target quality level, and encoder version. The table below shows results from five representative test images encoded at visually equivalent quality (SSIM ≥ 0.95) using cjpeg (MozJPEG 4.1) and cwebp (libwebp 1.4):

How WebP Works vs How JPEG Works

Understanding why WebP is smaller requires a basic understanding of both codecs.

JPEG was standardized in 1992. It divides an image into 8×8 pixel blocks, applies a Discrete Cosine Transform (DCT) to convert spatial data into frequency data, and then uses Huffman coding (a form of entropy coding) to compress the resulting coefficients. This block-based approach is why JPEG artifacts appear as visible 8×8 squares at low quality settings, each block is compressed independently, with no reference to neighboring blocks.

WebP was developed by Google based on the VP8 video codec (released 2010). For lossy encoding, it uses predictive coding, each block's values are predicted from neighboring blocks that have already been encoded, and only the residual (prediction error) is stored. This inter-block dependency allows WebP to represent smooth gradients and repeated textures far more efficiently than JPEG. The residuals are then compressed using arithmetic coding, which is more efficient than JPEG's Huffman coding at the cost of slightly higher encoder/decoder complexity.

The net result: WebP blocks can reference up to three adjacent previously-decoded blocks for prediction, whereas JPEG cannot. On real-world photographic content, this predictive approach captures about 25–35% more information per bit.

Quality Metrics: SSIM and DSSIM Explained

Comparing compressed images by file size alone is misleading if the quality differs. The two metrics most commonly used in professional image pipeline work are:

• SSIM (Structural Similarity Index): Measures luminance, contrast, and structural information simultaneously. A score of 1.0 means the images are identical. Values above 0.95 indicate excellent quality; values below 0.85 are typically visible to a casual viewer.
• DSSIM (Dissimilarity): Simply 1 − SSIM (or a variant thereof). Lower is better. A DSSIM below 0.005 is considered excellent; above 0.02 suggests visible artifacts.

When comparing WebP and JPEG, always match at equal SSIM, not equal encoder quality setting. A JPEG at quality 80 and a WebP at quality 80 do not produce equivalent visual results, WebP's quality scale is not the same as JPEG's. The correct comparison: encode both until they reach the same SSIM score, then compare file sizes. That's what the benchmark table above reflects.

When JPEG Still Wins

Despite WebP's compression advantage, there are scenarios where JPEG remains the more practical choice:

• Universal compatibility: JPEG is supported everywhere, every browser, every email client, every image editing tool, every OS-level viewer. WebP requires iOS 14+, macOS 11+, and is not supported by older Android WebViews or Outlook on Windows. For any context where you cannot use the <picture> element fallback (email, PDF, Word documents, some CMS exports), JPEG is the safe default.
• Exif and metadata preservation: JPEG has decades of tooling support for Exif, IPTC, and XMP metadata. Copyright, GPS, camera settings, and color profiles are well-supported in JPEG workflows. WebP supports Exif and XMP, but many tools strip or corrupt this metadata on encode/decode cycles.
• Editing and re-encoding: If an image will be edited and re-saved multiple times (e.g., in a content team's workflow), JPEG's generation loss is well-understood. WebP tools are less mature in professional editing workflows, and unexpected quality loss can occur when round-tripping through applications that don't fully implement the spec.
• Tooling ecosystem: Lightroom, Photoshop, Capture One, and most DAM platforms treat JPEG as their primary export format. WebP export is available but often secondary, with fewer quality-tuning options exposed in the UI.

Migration Strategy: The picture Element Fallback

The recommended approach for web migration to WebP is to serve WebP to supporting browsers while transparently falling back to JPEG for those that don't. The HTML <picture> element makes this trivial:

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Mountain landscape at sunrise" width="1200" height="630">
</picture>

Browsers that support WebP will load hero.webp. All others, including IE11, older Safari, and Outlook's rendering engine if the template is viewed in a browser, will load hero.jpg. This pattern requires you to maintain both files, which roughly doubles storage but is manageable with a CDN or image optimization service that generates both formats on demand.

For server-side content negotiation, check the Accept: image/webp request header and serve the appropriate format dynamically. This eliminates the need for duplicate HTML markup.

AVIF: The Next Step Beyond WebP

AVIF (AV1 Image File Format) is the successor to WebP, based on the AV1 video codec. At equivalent visual quality, AVIF is typically 20–35% smaller than WebP and 40–60% smaller than JPEG. It also supports HDR, wide color gamut, and 12-bit depth natively.

As of early 2026, AVIF is supported in Chrome (85+), Firefox (93+), and Safari (16+), covering approximately 90% of browser market share. Encoding AVIF is significantly slower than WebP (often 10–50× slower), which makes it impractical for real-time encoding but excellent for pre-optimized asset pipelines. The <picture> element supports a three-tier fallback:

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

This gives maximum compression to modern browsers while maintaining full backward compatibility.