WebP Image Format: Google's Modern Image Standard Explained
WebP is a modern image format developed by Google, introduced in 2010. Built on the VP8 video codec for lossy compression and PNG-style predictive coding for lossless, WebP delivers significantly smaller file sizes than JPEG and PNG while supporting features both formats lack: animation (like GIF), full alpha transparency in lossy mode, and metadata embedding. With browser support now exceeding 97% globally, WebP has become the preferred format for web image delivery.
Technical Foundation
Lossy WebP
Lossy WebP uses the VP8 intra-frame coding algorithm — the same technology used for VP8 video keyframes. The encoding process:
-
Color space conversion: RGB → YCbCr (luma + two chroma channels). Chroma channels are downsampled 4:2:0 (half resolution horizontally and vertically), exploiting human visual system's lower sensitivity to color than brightness.
-
Macroblock prediction: The image is divided into 16×16 macroblocks (for luma) and 8×8 blocks (for chroma). Each block's values are predicted from previously encoded adjacent blocks using one of 10 prediction modes (horizontal, vertical, DC, diagonal, etc.).
-
DCT transform: The prediction residual (actual − predicted values) is transformed using the Discrete Cosine Transform, converting spatial data to frequency coefficients.
-
Quantization: DCT coefficients are divided by a quantization matrix (controlled by the quality parameter 0–100). Higher quantization = more coefficient information discarded = smaller file + lower quality.
-
Arithmetic coding: Quantized coefficients are entropy-coded using VP8's boolean arithmetic coder (more efficient than JPEG's Huffman coding).
Lossless WebP
Lossless WebP uses a completely different approach based on backward reference coding:
- Predictive coding: Each pixel is predicted from its spatial neighbors using one of 14 prediction modes
- Color transform: Applies a 2D color transformation to decorrelate R, G, B channels
- Color indexing: Palettizes images with few unique colors (similar to PNG's indexed mode)
- LZ77 + Huffman: Encodes the residual data using LZ77 backward references and Huffman coding
- 2D backward references: Unlike PNG's row-only references, WebP can reference matching regions from any 2D position in the already-decoded image
Lossless WebP is typically 26% smaller than equivalent PNGs.
WebP Animation (ANIM)
Animated WebP uses an ANIM chunk (global parameters) + repeated ANMF chunks (per-frame data):
RIFF header
WEBP chunk
VP8X chunk — canvas size, animation flag, alpha flag
ANIM chunk — background color, loop count
ANMF chunk 1 — frame 1: position, size, duration, blend mode, frame data
ANMF chunk 2 — frame 2
...
Each frame can be lossy or lossless independently. The blend mode controls whether frames composite (alpha blending) or replace the canvas (no blending). Animated WebP consistently achieves 50–80% smaller files than equivalent GIFs.
File Size Comparison
Typical reductions vs. legacy formats:
| Content Type | vs. JPEG | vs. PNG | vs. GIF |
|---|---|---|---|
| Photographs (lossy) | 25–34% smaller | — | — |
| Graphics with transparency (lossless) | — | 26% smaller | — |
| Graphics with transparency (lossy) | — | 60–70% smaller | — |
| Animations | — | — | 50–80% smaller |
Browser and Platform Support
As of 2024:
- Chrome/Edge/Opera: Full support since 2014
- Firefox: Full support since Firefox 65 (2019)
- Safari: Full support since Safari 14 / macOS Big Sur (2020)
- iOS Safari: Full support since iOS 14 (2020)
- Global browser support: ~97%
Platform support: Google Photos, Gmail attachments, most CDNs, Cloudflare Image Resizing, Imgix, Cloudinary all serve WebP natively. Facebook, Twitter/X, and Google Images accept WebP uploads.
Notable gaps: Some email clients (Outlook desktop) do not render WebP inline. For email images, JPEG/PNG remains safer.
Converting to WebP
cwebp (Google's official encoder)
# Lossy encoding (default quality 75)
cwebp input.jpg -q 80 -o output.webp
# Lossless encoding
cwebp -lossless input.png -o output.webp
# Near-lossless (reduces size while being visually lossless)
cwebp -near_lossless 40 input.png -o output.webp
# Animated WebP from frames
img2webp -d 100 frame1.png frame2.png frame3.png -o animation.webp
ffmpeg
# Image to lossy WebP
ffmpeg -i input.jpg -c:v libwebp -quality 80 output.webp
# PNG to lossless WebP
ffmpeg -i input.png -c:v libwebp -lossless 1 output.webp
# GIF to animated WebP
ffmpeg -i input.gif -c:v libwebp_anim -quality 70 -loop 0 output.webp
# Video clip to animated WebP
ffmpeg -i input.mp4 -vf "fps=15,scale=480:-1" \
-c:v libwebp_anim -quality 70 -loop 0 \
-t 5 output.webp
ImageMagick
# Convert to WebP
convert input.png -quality 80 output.webp
# Batch convert all JPEGs in directory
mogrify -format webp -quality 80 *.jpg
Quality Setting Guide
| Quality | Use Case | Typical Size vs. JPEG |
|---|---|---|
| 90–100 | Near-lossless, archival | Similar or larger |
| 80–89 | High quality web images | 20–30% smaller |
| 70–79 | Standard web delivery | 30–40% smaller |
| 60–69 | Social media, thumbnails | 40–50% smaller |
| <60 | Aggressive compression | 50%+ smaller |
Quality 80–85 is the typical sweet spot for web delivery, matching JPEG quality 90+ at significantly smaller file sizes.
Serving WebP with Fallback (HTML)
<!-- Modern approach: <picture> element with fallback -->
<picture>
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Description" width="800" height="600">
</picture>
This serves WebP to supporting browsers and falls back to JPEG/PNG for older browsers (primarily Outlook and legacy Safari). The <img> tag is required as the fallback.
Apache server-side WebP delivery
# In .htaccess — serve .webp if browser accepts it and file exists
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule (.+)\.(jpe?g|png)$ $1.%2.webp [T=image/webp,E=accept:1]
Header append Vary Accept env=REDIRECT_accept
nginx
map $http_accept $webp_suffix {
default "";
"~*webp" ".webp";
}
location ~* \.(jpe?g|png)$ {
add_header Vary Accept;
try_files $uri$webp_suffix $uri =404;
}
WebP Limitations
-
Metadata support: WebP supports Exif, XMP, and ICC profile chunks, but some tools strip metadata on conversion — always check with
exiftool output.webp. -
Editing workflow: Lossless WebP is suitable for intermediate editing steps. Lossy WebP should be treated as a delivery format — re-encoding lossy WebP causes generation loss similar to JPEG.
-
Print: WebP uses 8-bit color depth in standard mode. For printing requiring 16-bit or CMYK color spaces, use TIFF or PNG.
-
Email client support: Outlook for Windows does not render WebP images inline. Use JPEG/PNG for email campaigns.
-
HDR: WebP supports limited HDR (via VP8X extended features), but AVIF and JPEG XL offer better HDR support for photography.
WebP vs. AVIF vs. JPEG XL
| Feature | WebP | AVIF | JPEG XL |
|---|---|---|---|
| Compression (photos) | -30% vs JPEG | -50% vs JPEG | -60% vs JPEG |
| Lossless | ✅ | ✅ | ✅ |
| Animation | ✅ | ✅ | ✅ |
| HDR | Limited | ✅ Full | ✅ Full |
| Browser support | 97% | 95% | ~80% |
| Encoding speed | Fast | Slow | Medium |
| Decoding speed | Fast | Medium | Fast |
| Spec maturity | Stable | Stable | Stable (2022) |
For current web use, WebP is the pragmatic choice — it's fast, well-supported, and delivers excellent compression. AVIF is worth using for the highest compression needs where encoding time is acceptable.
Summary
WebP has matured into the web's default modern image format. Its VP8-based lossy compression, lossless mode, animated support, and full alpha transparency address all the major limitations of JPEG, PNG, and GIF in a single format. With 97%+ browser support, the main barrier to adoption has been eliminated. For any web image delivery pipeline, converting JPEG and PNG assets to WebP (with HTML <picture> fallback) is a straightforward, high-impact optimization requiring no quality sacrifice.
Related conversions
Most teams that read this guide convert images in one of these directions: