Why isn't my WebP getting smaller — I expected substantial savings?

Likely because the source WebP was already well-encoded. Re-encoding an already-optimised lossy WebP at the same quality level produces minimal savings (often <5%) since VP8's quantisation is largely deterministic — re-running the encoder reproduces nearly identical output. The win comes from re-encoding at a LOWER quality than the source. If the source was quality 90 and you re-encode at quality 80, expect 30–40% reduction with minor visible loss. Note: re-encoding lossy WebP through any quality setting always introduces additional generation loss like JPEG, so always re-encode from a lossless master if available.

Compress WebP Online — Re-encode via VP8 (Lossy) or LZ77+Huffman (Lossless)

Q: Lossy vs lossless WebP compression — which should I pick?

Depends on source content. Lossy WebP (VP8 keyframes per RFC 6386 Bankoski et al., November 2011) at quality 80–85 typically delivers 25–35% smaller files than equivalent JPEG at the same perceptual quality, with no visible artefacts on photographs. Lossless WebP (LZ77 + Huffman/prefix coding + colour cache + four reversible transforms per RFC 9649 Zern, Massimino & Alakuijala, Google LLC, November 2024 §3) preserves every pixel exactly — averaging ~26% smaller than equivalent PNG per Google's WebP Compression Study. For photographic content go lossy; for graphics/logos/icons go lossless.

Q: Does Safari support WebP encoding for this tool?

Not natively as of 2026 — a long-standing WebKit limitation tracked at bugs.webkit.org. Chrome 18+ (2012), Edge 79+ Chromium-based (January 2020), and Firefox 96+ (January 2022) all support image/webp output via Canvas toBlob() natively; Firefox 98+ added the quality parameter, Firefox 105+ enabled lossless via quality=1.0. Safari users hit a JavaScript polyfill (typically libwebp compiled to WebAssembly) for the WebP encoding step, which is what browser-image-compression falls back to in Safari. The result is identical bit-for-bit; the only difference is performance (WebAssembly slower than native).

Q: Will WebP transparency survive compression?

Yes. WebP supports an 8-bit alpha channel both in lossless mode and as an extension in lossy mode (ALPH chunk per RFC 9649 §2.7.1.2). The compression pipeline (whether browser-native via Canvas toBlob('image/webp', quality) or libwebp WebAssembly polyfill on Safari) preserves alpha values exactly — every transparent pixel stays transparent, every semi-transparent pixel keeps its precise alpha byte. WebP-to-WebP re-compression is alpha-clean across all browsers and quality levels.

WebP Compressor — VP8 Lossy or LZ77+Huffman Lossless (RFC 9649)

WebP (RFC 9649 Zern, Massimino & Alakuijala, Google LLC, November 2024) supports two distinct compression modes. Lossy mode uses VP8 keyframes (RFC 6386 Bankoski et al., November 2011) — quality 1–100 controls VP8 quantiser, with 80–85 the typical web sweet spot delivering 25–35% smaller files than equivalent JPEG. Lossless mode uses LZ77 + Huffman/prefix coding + colour cache + four reversible transforms (per RFC 9649 §3) — preserves every pixel exactly while averaging ~26% smaller than equivalent PNG per Google's WebP Compression Study. The tool routes through Canvas toBlob('image/webp', quality) where quality 0–1 maps to VP8 quantiser scaling for lossy; Firefox 105+ supports quality=1.0 to trigger lossless mode. Critical Safari caveat: Safari does NOT support image/webp output via canvas.toBlob() as of 2026 — a long-standing WebKit limitation tracked at bugs.webkit.org. Safari users hit a libwebp WebAssembly polyfill via the browser-image-compression library.

How to compress a WebP

Drop a .webp file onto the tool or click to browse — single file or batch.
Pick a quality level. 80–85 is the typical web sweet spot for lossy; quality=100 (or 1.0 in Firefox 105+) triggers lossless mode.
Watch the savings percentage. WebP-to-WebP re-encoding gains depend heavily on source WebP's prior quality — well-optimised WebPs leave little room.
Download the compressed copy. Note: if you're on Safari, the conversion uses libwebp WebAssembly polyfill (slightly slower than native).

Common use cases

Re-compressing legacy WebP assets at lower quality (85 → 75) to cut total page weight before a Lighthouse audit.
Producing lossless WebP variants from already-lossy WebPs is generally NOT recommended — convert from a lossless master if available.
Trimming WebP screenshots for documentation or asset bundles where the original was saved at high quality.
Preparing WebP variants for HTML <picture> tags with PNG/JPG fallbacks for Safari pre-14 / iOS pre-14 audiences.

Frequently asked questions

Lossy vs lossless WebP compression — which should I pick?

Depends on source. Lossy (VP8 per RFC 6386, Nov 2011) at quality 80–85 typically 25–35% smaller than JPEG, no visible artefacts on photos. Lossless (RFC 9649 §3 LZ77 + Huffman + colour cache) preserves pixels exactly, ~26% smaller than PNG per Google. Photos → lossy; graphics → lossless.

Does Safari support WebP encoding for this tool?

Not natively as of 2026 — a WebKit limitation tracked at bugs.webkit.org. Chrome 18+ (2012), Edge 79+ (Jan 2020), Firefox 96+ (Jan 2022) support natively. Safari users hit a libwebp WebAssembly polyfill (bundled by browser-image-compression library).

How does WebP quality compare to JPEG quality?

Per Google's WebP Compression Study, lossy WebP at quality 80 is 25–35% smaller than JPEG quality 80 with comparable perceptual quality, thanks to VP8's more granular intra-prediction (10 modes for 4×4 luma sub-blocks plus 4 modes each for 16×16 luma macroblocks and 8×8 chroma per RFC 6386 §11–12) and arithmetic entropy coding vs JPEG's older 8×8 DCT + Huffman.

Will WebP transparency survive compression?

Yes. WebP supports 8-bit alpha in both lossless and lossy modes (ALPH chunk per RFC 9649 §2.7.1.2). Compression preserves alpha bytes exactly across browser-native and WebAssembly-polyfill paths.

Why isn't my WebP getting smaller?

Likely because the source WebP was already well-encoded. Re-encoding at the same quality produces minimal savings (often <5%) since VP8 quantisation is largely deterministic. The win comes from re-encoding at a LOWER quality — 90 → 80 typically 30–40% reduction with minor visible loss.

Lossy or lossless WebP — picking by content + the Safari encoding caveat

WebP's two compression modes match different content types cleanly. Lossy WebP (VP8 keyframes per RFC 6386) shines on photographic content — VP8's intra-prediction modes (4 modes for 16×16 luma macroblocks, 4 for 8×8 chroma, 10 modes for 4×4 luma sub-blocks per RFC 6386 §11–12) plus boolean arithmetic entropy coding pack natural-image entropy ~25–35% more efficiently than JPEG's 1992-era 8×8 DCT + Huffman. Lossless WebP (RFC 9649 §3) uses LZ77 with a colour cache and four reversible transforms (predictor, colour, subtract-green, indexed colour) before final Huffman/prefix coding — preserving every pixel exactly, ~26% smaller than equivalent PNG per Google's published study. Quality slider semantics: 1–100 controls VP8 quantiser for lossy; Firefox 105+ recognises quality=1.0 as a lossless trigger. Re-compression compounds loss like JPEG: re-encoding an already-lossy WebP at lower quality further degrades; always re-compress from a lossless master if available. Browser support asymmetry: Chrome 18+ (2012), Edge 79+ Chromium-based (January 2020), Firefox 96+ (January 2022) all support image/webp output natively; Safari does NOT — a WebKit limitation requiring libwebp WebAssembly polyfill (bundled by browser-image-compression). The polyfill produces bit-identical output to native encoding; the only difference is performance (WebAssembly slightly slower than native VP8 implementation). EXIF metadata: WebP supports EXIF chunk per RFC 9649 §2.7.1.5, but Canvas-based re-encoding strips it by default — opt-in preserveExif retains via browser-image-compression flag.

Quality 1–100 controls VP8 quantiser for lossy WebP (RFC 6386)
Lossless WebP via quality=1.0 (Firefox 105+) — preserves pixels via LZ77 + Huffman + colour cache
Browser-native encoding in Chrome 18+ / Edge 79+ / Firefox 96+; Safari uses libwebp WebAssembly polyfill
Alpha channel preserved (ALPH chunk per RFC 9649 §2.7.1.2) in both lossy and lossless modes
EXIF metadata stripped by default (privacy benefit) — opt-in preserveExif via browser-image-compression
Real-time size comparison with percentage savings

Free. No signup. No file uploads. Ads via AdSense (consent required).

Sources (5)

Zern, J., Massimino, P., & Alakuijala, J. (Google LLC) (2024). WebP Image Format. RFC 9649, IETF (November 2024, Informational) — WebP container with lossy mode (VP8 keyframes) and lossless mode (LZ77 + Huffman/prefix coding + colour cache); quality 1–100 controls VP8 quantiser for lossy.
Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., & Xu, Y. (Google Inc.) (2011). VP8 Data Format and Decoding Guide. RFC 6386, IETF (November 2011, Informational) — VP8 keyframe bitstream underlying WebP lossy mode; intra-prediction modes packed by boolean arithmetic coder.
WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext (toBlob('image/webp', quality) native in Chrome 18+, Edge 79+ Chromium, Firefox 96+; Firefox 105+ supports lossless via quality=1.0; Safari does NOT support image/webp output — requires libwebp WebAssembly polyfill).
Donald (Donaldcwl) (live). browser-image-compression. npm package v2.0.2 (github.com/Donaldcwl/browser-image-compression, MIT) — Canvas-based WebP re-encoding pipeline used by this tool; falls back to libwebp WebAssembly polyfill in Safari.
Google LLC (WebP team) (live). WebP Compression Study. developers.google.com/speed/webp/docs/webp_study — SSIM-based comparison; lossless WebP averages ~26% smaller than equivalent PNG; lossy WebP at quality 80–85 typically 25–35% smaller than JPEG.

These are the W3C, ISO/IEC, ITU-T, and IETF specifications the tool implements or builds on. Locate them on w3.org, iso.org, itu.int, or datatracker.ietf.org.