WebP Images — Why Switch From JPEG and PNG Today

If you're still serving JPEG and PNG as your primary image formats in 2026, you're making your users download more data than they need to. WebP has been broadly supported for years. The conversion tooling is mature. The HTML fallback pattern is a one-liner. There's no good reason to wait.

What WebP Actually Is

WebP is an image format developed by Google, released in 2010. It supports lossy and lossless compression, a full alpha channel for transparency, and animation — covering every use case that JPEG, PNG, and GIF handle individually, in a single format.

The compression derives from VP8, Google's video codec. For lossy images, WebP uses predictive coding: each pixel's value is predicted from neighboring pixels and only the difference is encoded, then compressed with Huffman and arithmetic coding. The result is meaningfully better than JPEG's 30-year-old DCT approach.

For lossless, WebP uses a separate algorithm that includes color transformation, spatial prediction, color indexing, and LZ77-based compression. PNG is also lossless, but WebP lossless typically produces files 26% smaller.

The Size Numbers

These aren't theoretical. Google published benchmark data comparing WebP to JPEG and PNG at matched quality levels:

WebP lossy: 25–34% smaller than JPEG at equivalent SSIM quality scores
WebP lossless: 26% smaller than PNG on average
WebP animated: 60–80% smaller than GIF for equivalent animations

The savings vary by image content. Photographs with complex textures compress less dramatically than images with large uniform areas. But on a real website image library, 30% average savings is a reasonable expectation for switching from JPEG to WebP.

What does that mean in practice? A product page with 10 images averaging 150KB each — 1.5MB in JPEG — becomes roughly 1MB in WebP. Over thousands of page loads, that's measurable impact on load time, bandwidth costs, and Core Web Vitals scores.

Browser Support: The Objection That No Longer Applies

The historical argument against WebP was browser support. That argument is over.

Chrome: supported since version 23 (2013)
Firefox: supported since version 65 (2019)
Safari: supported since iOS 14 and macOS Big Sur (late 2020)
Edge: supported since Chromium-based Edge (2020)
Samsung Internet, Opera: supported

Global WebP support is above 97% of browsers. The remaining 2–3% is dominated by old iOS Safari (pre-14) and very old desktop browsers. If you need to support those, use the <picture> fallback pattern below. If you don't, serve WebP directly.

Converting: Three Approaches

CLI with cwebp

Google's cwebp encoder is the reference implementation. It's available via package managers on all platforms.

# Basic conversion
cwebp input.jpg -o output.webp

# Set quality (0-100, default 75)
cwebp -q 80 input.jpg -o output.webp

# Lossless mode (for PNG equivalents)
cwebp -lossless input.png -o output.webp

# Batch convert all JPEGs in a directory
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done

Sharp in Node.js

Sharp is the standard image processing library for Node.js. It wraps libvips and handles WebP conversion efficiently, even at scale.

import sharp from 'sharp';

// Convert JPEG to WebP
await sharp('input.jpg')
  .webp({ quality: 80 })
  .toFile('output.webp');

// Convert PNG to lossless WebP
await sharp('input.png')
  .webp({ lossless: true })
  .toFile('output.webp');

// Batch conversion
import { glob } from 'glob';
import path from 'path';

const files = await glob('images/**/*.{jpg,jpeg,png}');
await Promise.all(files.map(async (file) => {
  const outPath = file.replace(/\.(jpg|jpeg|png)$/, '.webp');
  await sharp(file).webp({ quality: 82 }).toFile(outPath);
}));

In the Browser

The Image Convert tool converts images to WebP directly in your browser — no server round trip, no software to install. Upload a JPEG or PNG, pick WebP as the output format, and download. Useful for one-off conversions and for checking what a converted file will look like before committing to a batch process.

Serving WebP with HTML Fallback

The <picture> element lets you serve WebP to browsers that support it while falling back to JPEG or PNG for the rest.

<picture>
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="A descriptive alt text" loading="lazy" width="800" height="600">
</picture>

Browsers that support WebP pick the <source> element. Browsers that don't fall through to the <img>. The type="image/webp" attribute is the key — the browser uses it to check format support before requesting the file.

For responsive images, combine WebP sources with srcset and sizes:

<picture>
  <source
    type="image/webp"
    srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1200.webp 1200w"
    sizes="(max-width: 600px) 100vw, 800px">
  <img
    src="photo-800.jpg"
    srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1200.jpg 1200w"
    sizes="(max-width: 600px) 100vw, 800px"
    alt="Description"
    loading="lazy"
    width="800"
    height="600">
</picture>

This is verbose but covers every case: format selection, responsive sizing, and fallback. Most modern frameworks (Next.js, Nuxt, Astro) handle this automatically via their image components.

WebP in CSS Background Images

CSS doesn't have the <picture> element's built-in fallback mechanism. The cleanest approach uses the .webp class on <html>, set by a feature detection script:

// Detect WebP support and mark the document
const img = new Image();
img.onload = img.onerror = () => {
  document.documentElement.classList.toggle('webp', img.height === 1);
};
img.src = 'data:image/webp;base64,UklGRiQAAABXRUJQVlA4IBgAAAAwAQCdASoBAAEAAQAcJZACdAYO/gHOAAA=';

Then in CSS:

.hero {
  background-image: url('hero.jpg');
}

.webp .hero {
  background-image: url('hero.webp');
}

Alternatively, use @supports for a CSS-native approach, though browser support for image format detection via @supports is less reliable than JavaScript detection.

In practice, if you're targeting modern browsers (97%+ global coverage), you can often just serve WebP directly as CSS backgrounds without fallback logic.

Common Conversion Mistakes

Setting quality too low. WebP quality 75 is not equivalent to JPEG quality 75 — WebP achieves better results at lower quality numbers. A WebP at quality 80 often looks better than JPEG at quality 85 while being smaller. Don't blindly match quality numbers. Check the visual output.

Forgetting lossless for transparency. Converting a PNG with transparency? Use WebP lossless or set the preserve-alpha option. Lossy WebP with transparency works but may degrade edges around transparent areas.

Converting already-lossy files. Converting JPEG to WebP transcodes from one lossy format to another, compounding quality loss. If you have original source files (RAW, TIFF, high-quality master JPEGs), start from those. If you only have JPEGs, the quality loss from transcoding is usually acceptable but not zero.

Not setting explicit dimensions. When serving WebP with <picture>, keep width and height attributes on the <img> element. These attributes let the browser reserve layout space before the image loads, preventing layout shift and improving Cumulative Layout Shift (CLS) scores.

AVIF: The Next Step

WebP is the right default today. AVIF is the next upgrade when you can afford it.

AVIF compresses 40–50% better than JPEG and 20–30% better than WebP at matched quality. It's based on the AV1 video codec and supports HDR, wide color gamut, and everything WebP does. Safari 16+ (2022) and all modern Chrome and Firefox support it.

The barrier is encoding speed — AVIF encoding is 5–10x slower than WebP, which makes batch conversion more expensive. For a typical web deployment, a common approach is AVIF with WebP fallback:

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

Read Image Formats Explained for the full comparison of when each format wins.

Wrapping Up

The migration from JPEG and PNG to WebP is well-established. Convert with cwebp or Sharp, serve with the <picture> fallback, and you'll see measurable page weight reduction with no visible quality loss. For individual file conversion, Image Convert handles it directly in the browser, and Image Compress lets you tune quality until the size/quality tradeoff lands where you need it.