WebP vs JPEG: File Size, Quality, and When to Switch

720 words 4 mins read

Compare WebP lossy and JPEG on file size, SSIM quality metrics, encode speed, and feature set to decide when switching makes sense for your photos.

WebP lossy compression and JPEG have competed for the same territory — photographic web images — since Google introduced WebP in 2010. Both formats discard perceptual data to achieve smaller files, but they do it differently, and understanding those differences helps you make the right choice for your images, your users, and your delivery pipeline.

File Size #

WebP lossy produces files that are, on average, 25–34% smaller than JPEG at equivalent SSIM (Structural Similarity Index). That means you can deliver the same perceived quality to your users at a meaningfully lower bandwidth cost.

When you fix a target SSIM of 0.99 — a level that looks essentially identical to the original — WebP files are consistently smaller than their JPEG counterparts across a wide variety of photographic content. The savings are most pronounced on images with smooth gradients, skin tones, and fine textures, where JPEG’s DCT-based blocking tends to show up first.

Switching hero images from JPEG to WebP commonly produces a measurable improvement in Largest Contentful Paint (LCP), one of Google’s Core Web Vitals, because the browser finishes downloading the larger above-the-fold image sooner.

Quality Metrics #

File size alone does not tell you whether two images look the same. SSIM (Structural Similarity Index) measures perceived image quality by comparing luminance, contrast, and structure between a reference image and a compressed version, producing a score between 0 (no similarity) and 1 (identical). A higher SSIM means the compressed image looks more like the original.

SSIM matters more than raw file size or PSNR (Peak Signal-to-Noise Ratio) because it correlates better with how humans actually perceive image degradation. PSNR treats every pixel error equally; SSIM understands that blurring a flat sky is less noticeable than blurring an eye.

At the same bitrate, WebP tends to produce fewer blocking artifacts and less ringing around sharp edges than JPEG. JPEG’s 8×8 DCT blocks become visible as the quality setting drops, while WebP’s VP8 codec uses larger, adaptive transform blocks that degrade more gracefully.

Feature Comparison #

Lossy compression — WebP: supported. JPEG: supported.
Lossless compression — WebP: supported. JPEG: not supported.
Alpha transparency — WebP: supported. JPEG: not supported.
Animation — WebP: supported. JPEG: not supported.
Progressive loading — WebP: supported. JPEG: supported.
HDR / wide colour — WebP: limited. JPEG: limited.
Universal browser support — WebP: 95%+ globally. JPEG: 100%.

WebP’s support for lossless compression, alpha transparency, and animation makes it a more versatile container than JPEG, which handles only lossy, opaque, still images.

Encoding Speed #

JPEG typically encodes faster than WebP at equivalent quality settings. WebP’s default encoding method (-m 4) strikes a reasonable balance between compression ratio and CPU time, but if you are processing large batches in real time you will notice the difference.

The WebP encoder exposes a -m flag (0–6) that trades encoding speed for compression efficiency. Method 4 is the default. Method 6 produces the smallest files but is significantly slower. For build-time asset pipelines, method 6 is often worthwhile; for on-the-fly image resizing, method 2 or 3 is a better fit.

The following commands show the same image encoded at three different method levels so you can compare the speed and size trade-offs directly:

# Fast (method 2)
cwebp -m 2 -q 82 photo.jpg -o photo.webp

# Balanced (method 4 — default)
cwebp -m 4 -q 82 photo.jpg -o photo.webp

# Best compression (method 6)
cwebp -m 6 -q 82 photo.jpg -o photo.webp

When to Keep JPEG #

WebP is not always the right answer. Stick with JPEG when:

Legacy Systems #

Your image processing pipeline — CDN, CMS, or image transformation service — does not support WebP encoding or serving.

JPEG-Only Tooling #

Your editorial or design workflow outputs JPEG exclusively and adding a conversion step introduces unacceptable complexity or quality uncertainty.

Very Old Browser Requirements #

You must support browsers like Internet Explorer 11 or Safari versions before 14, which do not render WebP. WebP browser support sits at 95%+, but the remaining 5% matters for some audiences.

Interchange Format #

You are exchanging images with partners or users who expect JPEG and cannot guarantee they have WebP-capable software on their end.

If you receive WebP files but your recipients need JPEG, convert WebP to JPG online before sending — no software installation required.

Migration Checklist #

Follow these steps to migrate photo assets from JPEG to WebP safely and measure the real-world impact.

Benchmark your specific image set — Run a sample of 20–50 representative images through both encoders at your current quality settings. Record file sizes and SSIM scores. Do not rely solely on published averages — your image corpus may behave differently.
```
# Convert a batch and compare sizes
for f in samples/*.jpg; do
  cwebp -q 82 "$f" -o "${f%.jpg}.webp"
done
du -sh samples/*.jpg samples/*.webp | sort -h
```
Choose a quality target — A quality setting of 80–85 is the recommended starting point for photographic WebP. This range delivers visually lossless results for most images while keeping files well below their JPEG equivalents. Adjust up for product photography where fine detail matters, or down for thumbnails.
Implement the picture element with JPEG fallback — Never serve WebP without a fallback. Use the HTML <picture> element so browsers that do not support WebP gracefully receive the JPEG version.
```
<picture>
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Hero image" width="1200" height="630" />
</picture>
```
Measure Core Web Vitals before and after — Use Chrome DevTools, PageSpeed Insights, or the CrUX dashboard to record your LCP, CLS, and FID scores before you deploy the WebP versions. Re-measure after deploying to confirm the expected improvement and catch any regressions introduced by the migration.

Was this page helpful?