About

WebP lossy compression operates on a block-prediction model derived from VP8 video codec. The encoder partitions each frame into macroblocks, applies spatial prediction, then quantizes the residual transform coefficients. Reducing the q parameter increases quantization step size, discarding high-frequency detail first. A file saved at quality 80 typically loses 2 - 4 dB of PSNR relative to the original, yet achieves 40 - 60% byte reduction. Choosing the wrong quality floor can produce visible banding in gradients or ringing around edges. This tool re-encodes through the browser’s native WebP codec via Canvas, so results depend on your browser’s libwebp build. It approximates server-side cwebp output but does not expose advanced flags like -segments or -sns.

Batch uploads are processed sequentially to avoid exceeding the browser memory budget. Alpha channels are preserved during re-encoding. Note: lossless-to-lossy conversion always introduces generation loss. If your source is already a heavily compressed JPEG converted to WebP, re-compressing yields diminishing returns and may enlarge the file at quality settings above the original encode threshold.

Formulas

The compression ratio and savings are computed from the raw byte sizes of the original and re-encoded blobs.

R = S_original − S_compressedS_original × 100%

Where R is the reduction percentage, S_original is the original file size in bytes, and S_compressed is the output blob size. A negative R indicates the output grew larger than the input, which occurs when re-encoding an already-optimized file at a higher quality setting.

CR = S_originalS_compressed

The compression ratio CR expresses how many times smaller the output is. A CR of 3.0 means the file is one-third its original size.

When optional resizing is applied, the canvas dimensions are capped:

w_out = min(w_in, w_max) h_out = w_out × h_inw_in

Where w_max is the user-specified maximum width and aspect ratio is preserved by deriving h_out proportionally.

Reference Data

Quality Setting	Typical Size Reduction	PSNR Loss (dB)	SSIM Range	Best Use Case
95 - 100	5 - 15%	< 0.5	0.99 - 1.00	Archival, medical imaging
85 - 94	20 - 35%	0.5 - 1.5	0.97 - 0.99	Photography portfolios
75 - 84	35 - 55%	1.5 - 3.0	0.94 - 0.97	E-commerce product images
60 - 74	55 - 70%	3.0 - 5.0	0.90 - 0.94	Blog illustrations, thumbnails
40 - 59	70 - 82%	5.0 - 8.0	0.84 - 0.90	Social media previews
20 - 39	82 - 90%	8.0 - 12.0	0.75 - 0.84	Placeholder / blur-up images
1 - 19	90 - 97%	> 12.0	< 0.75	Extreme bandwidth constraints
Format Comparison (at equivalent visual quality)
WebP vs JPEG	25 - 34% smaller	Google comparative study, 2023
WebP vs PNG (lossy)	26 - 34% smaller	Lossless WebP vs PNG: ~26%
WebP max dimensions	16383 × 16383 px (VP8L spec limit)
WebP max file size	4 GiB (RIFF container limit, ~2³² bytes)
Browser Canvas limit	Varies: Chrome ~16384px, Safari ~4096px on iOS
Alpha channel	Supported in both lossy and lossless WebP
Animation	Supported (this tool processes first frame only)

Frequently Asked Questions

This happens when the original WebP was encoded at a lower quality than your selected setting, or when the source is a lossless WebP and you re-encode at near-100 lossy quality. The encoder adds lossy codec overhead that exceeds the original byte count. Lower your quality slider below the original encode threshold - typically below 75 - to see actual savings.

Yes. The Canvas API pipeline decodes pixel data only. All EXIF, XMP, ICC color profile, and RIFF metadata chunks are discarded during re-encoding. If you need to preserve metadata, use a server-side tool like cwebp with the -metadata flag.

Browsers expose only the quality parameter (0.0-1.0) via canvas.toBlob(). You cannot control spatial noise shaping (-sns), segmentation (-segments), filter strength (-f), or preprocessing (-pre). Chrome uses libwebp internally but with fixed partitioning. Results are close to cwebp -q N but not byte-identical. For production CDN pipelines, server-side encoding gives finer control.

Yes. The canvas is not pre-filled with a background color, so transparent pixels remain transparent in the output WebP. However, lossy encoding may introduce slight fringing at transparency edges. For critical alpha quality, keep quality above 85 or use lossless mode (quality 100 in some browsers triggers lossless).

It depends on your browser's canvas memory limit. Chrome allows approximately 16384 × 16384 px on desktop. Safari on iOS caps at roughly 4096 × 4096 px. Exceeding these limits causes the canvas to silently produce a blank image. The tool detects this and shows an error. Use the resize option to cap dimensions below your browser's limit.

Only the first frame is processed. The Canvas API does not expose animation frames from WebP. To compress animated WebP while preserving animation, use a CLI tool like webpmux combined with cwebp, or the libwebp API directly.