Why would I compress an already-compressed WebP?

Many WebP files in circulation were encoded at quality 90+ or with default-effort encoder settings (encoder method 4). Re-encoding at quality 75–82 with higher effort can shrink them another 20–40% with no visible quality change.

Won't compressing again make the image look worse?

At quality 75 or above, the second-pass quality loss is rarely visible on photographic content. Below 70, lossy compression starts to introduce noticeable artefacts — particularly on content with hard edges or text overlays.

What quality should I use?

For hero images, 82. For body imagery, 78. For thumbnails, 65–72. For decorative or below-the-fold content, 55–65. If the source was lossless WebP (logos, icons), don't re-compress as lossy — use the original.

Will my files be uploaded?

No. Compression happens entirely in your browser via the Canvas API. Your WebP files never leave your device. This works on enterprise networks, on metered connections, and offline once the page is loaded.

Will transparency be preserved?

Yes. The Canvas API decodes the alpha channel from the source WebP and re-encodes it in the output. Both lossy and lossless source WebPs round-trip transparency correctly.

What if the output is larger than the input?

This happens when the source is already heavily compressed or encoded with sophisticated encoder settings the Canvas API can't match. The tool will report 'size increased' — at that point, keep the original file rather than the recompressed version.

Can I compress multiple WebP files at once?

The current tool processes one file at a time. For bulk operations, use cwebp or Sharp in a build pipeline with consistent quality settings.

Does this work on animated WebP?

It processes the first frame only. The Canvas API doesn't read animated-WebP frame data. For animated WebP optimisation, use a dedicated tool like gif2webp or img2webp from the libwebp suite.

What's the file size limit?

No artificial limit. Browser memory is the practical constraint — files up to ~50 MB are comfortable; very large files (100 MB+) may slow on lower-end devices.

Is browser-based compression as good as server-side encoding?

Not quite. Server-side tools like cwebp -m 6 use higher encoder effort settings that aren't exposed via the Canvas API. For maximum compression, use cwebp or Sharp in a build pipeline. For ad-hoc work, the browser-based approach is fast and convenient.

Compress WebP files in your browser

Re-encode existing WebP files at lower quality to shrink them further. Most WebPs in circulation were encoded at quality 90+ and can lose 20–40% of their size with no visible change.

Adjustable qualityTransparency preservedSide-by-side previewClient-side only

Click to select your WebP file

File never leaves your browser.

Quick start

Step 1
Select your WebP file
Click the upload area or drag and drop a WebP file. One file at a time for the compression tool.
Step 2
Choose a quality setting
Use the slider to set the target quality (10–100). 78 is a safe default; lower for thumbnails, higher for heroes.
Step 3
Compress and download
Click compress. The tool re-encodes the WebP at your chosen quality and reports the size reduction. Download when ready.

How WebP compression works

Compressing a WebP is a re-encode. The browser decodes the source WebP into RGBA pixels via the Canvas API, then encodes those pixels as a new WebP at the quality setting you choose. This produces a smaller file at the cost of some additional quality loss compared to the source.

The size win comes from lowering the quality factor — most existing WebPs in circulation were encoded at quality 90+ to be safe, when 78–82 would have produced visually equivalent output at significantly smaller size. The visible difference between quality 90 and quality 80 is almost never perceptible on a typical display; the file size difference is routinely 30–40%.

A few cases where compression won't help:

The source WebP is already at quality 75 or below. Re-compression produces marginal savings and may introduce visible artefacts.
The source is lossless WebP (logos, icons, screenshots). Re-encoding as lossy adds artefacts. Keep the lossless original.
The source was encoded with sophisticated server-side tools (cwebp -m 6, Sharp at effort=6) that produce smaller output than the Canvas API can match.

For systematic compression guidance, see WebP Compression Settings and Lossy vs Lossless Compression.

When to compress a WebP

Inherited high-quality WebPs

Files exported from Photoshop, Affinity, or Figma often default to quality 90+. Re-compressing at 78–82 typically cuts size by 30–40% with no visible difference.

CDN-converted WebPs

Some CDN auto-conversion services produce safe-but-large WebPs. Manual re-compression often reclaims meaningful bytes.

Hero / LCP optimisation

The Largest Contentful Paint image typically dominates page weight. Aggressive compression on the hero (q=78–82) has outsized Core Web Vitals impact.

Targeting a byte budget

Some platforms enforce maximum file sizes (ad networks, marketplace listings). Re-compress at incrementally lower quality until you hit the budget.

Thumbnails and below-the-fold

Images rendered at small sizes can tolerate aggressive compression (q=65–72) invisibly. The compression saving compounds across grid pages with many thumbnails.

Bandwidth-sensitive audiences

Mobile-first or emerging-market audiences benefit from every kilobyte saved. Compress aggressively for these contexts.

Quality settings

Use case	Quality	Notes
Hero / above-the-fold	82	Visible at large size; quality matters
Product imagery	78	Sweet spot for ecommerce
Article body imagery	75	Almost always indistinguishable
Thumbnails (≤ 200px)	65–72	Aggressive compression invisible at size
Decorative / background	55–65	Detail loss acceptable

Below quality 55, lossy artefacts (block boundaries, ringing around edges) become visible on typical content. Above quality 90, file size grows much faster than quality improves — avoid this range unless archival fidelity is required.

Common issues and solutions

Output file is larger than the input

The source WebP was encoded with sophisticated server-side encoder settings the Canvas API can't match. Keep the original — re-compression won't help.

Output looks visibly worse

Quality setting is too aggressive. Try 78–82 for photographic content. For logos, icons, or text-heavy graphics, don't use this tool — the source is probably lossless and should stay that way.

Transparency is missing in the output

Should not happen — the Canvas API preserves alpha channels through re-encoding. If transparency is lost, verify by opening the source in another tool to confirm it had transparency to begin with.

Compression is slow on large files

Very large files (50 MB+) stress browser memory. Try downscaling first, or use a server-side encoder for high-volume batch work.

I want to batch-compress many WebPs

For batch operations, use a build pipeline with Sharp or cwebp at -m 6. Browser-based compression is ideal for one-off tuning; build pipelines are better for scale.

Quality 100 still shows reduction

The Canvas API's WebP encoder doesn't truly support lossless via the q=100 setting alone. For genuinely lossless re-encoding, use cwebp -lossless server-side.

Animated WebP loses animation

The Canvas API only reads the first frame. For animated-WebP re-compression, use img2webp or gif2webp from the libwebp suite.

I get a 'Compression failed' error

Usually means the source file is corrupted or uses an unusual WebP profile. Try opening it in another tool to verify the file is valid.

Frequently asked questions

Need WebP first?

JPG to WebP Converter →

Convert JPG to WebP with full quality control before further compression.

Need WebP first?

PNG to WebP Converter →

Convert PNG to WebP. For photographic PNGs, use lossy mode at q=80; for graphics, use lossless (q=100).

Format detail

WebP format overview →

Container structure, codec details, browser support, and implementation patterns.

Encoder reference

WebP Compression Settings →

Complete reference for quality, method, alpha-quality, near-lossless, and preset parameters.

Guide

WebP Optimisation →

Encoder settings, responsive delivery, lazy loading, and Core Web Vitals impact for WebP.