Oversized WebP exports are a real problem
WebP earned its reputation as the smaller-than-JPG web format, so it is easy to assume any .webp file is already optimized. In practice, export pipelines betray that assumption constantly: Figma plugins, CMS image processors and screenshot tools frequently write WebP at maximum quality or in lossless mode, producing 1 to 3 MB files for images that should weigh 100 to 300 KB. Those bytes show up directly in your Largest Contentful Paint and your Core Web Vitals report. Re-encoding with libwebp at a deliberate quality setting, usually 70 to 85, brings each asset back inside a sane performance budget. The result rows show the exact before and after sizes, so you can audit a whole batch of site assets in one pass. For assets that are still JPG or PNG, start with Compress JPG or the lossless Compress PNG instead.
Fitting a performance budget without a build pipeline
Teams with full image pipelines automate this with sharp or squoosh-cli, but plenty of real work happens outside a build system: a marketing landing page, a WordPress upload, a client handoff of exported assets. This page fills that gap. Drop up to 200 WebP files, set one quality, and download a ZIP of re-encoded results with per-file savings you can paste into a PR description. Because the encoder is compiled to WebAssembly and runs on your own machine, there are no upload queues, no per-file size ceilings and no monthly quotas, and confidential design work stays on your device. If a recipient cannot open WebP at all, an old mail client for example, convert with WebP to JPG; for mixed folders of JPG, PNG and WebP, the general Compress Image tool handles every format in one batch.
Common questions
Why is my WebP file so large in the first place?+−
WebP is only as efficient as the settings used to create it. Many design tools and export plugins write WebP at quality 90 to 100, or even in lossless mode, to be safe. That can produce files larger than a decent JPG. Re-encoding at quality 75 to 85 usually recovers most of the wasted bytes while looking identical at normal viewing sizes.
What quality should I pick for web images?+−
Quality 80 is a safe default for hero images and photography, and 65 to 75 works well for thumbnails, cards and backgrounds where fine detail is less visible. Check the savings column after compressing: if an asset is still over your performance budget, step the slider down and run it again. Going above 90 inflates files quickly with little visible benefit.
Does re-compressing WebP lose quality?+−
This is a lossy re-encode, so some information is discarded, but a single pass at quality 75 to 85 is visually transparent for photos and typical page imagery. Avoid repeatedly re-encoding the same file through many cycles, and keep your original export as the master. If your source is a lossless WebP such as a screenshot, the visual change from one encode is negligible.
Are there file limits, and where do my images go?+−
There are no meaningful limits: unlimited files overall, up to 200 per batch, no size caps and no watermarks. Compare that with TinyPNG, which is a fine service but caps its free tier at 20 images of 5 MB each and processes files on its servers. Here libwebp runs in your browser, so your images never leave your device.