Compress WEBP images with smart curve algorithm and live split-preview
WEBP Compressor
Compress WEBP images with smart curve algorithm and live split-preview
CHOOSE FILES
(or drag them here)
Your WebP files can probably be smaller than they already are
Most tools that convert images to WebP play it safe and use quality 80–85 by default. That’s conservative — it avoids complaints but leaves a lot of file size on the table. Re-encoding a WebP from quality 85 down to quality 72 typically cuts another 30–40% off the file, and on a normal monitor you genuinely cannot see the difference.
Which quality to use for each type of image
- Photos — lossy, quality 72–80
- Photos have natural grain and gradients that hide compression artefacts really well. Quality 72 on a photo looks the same as quality 85 on any standard screen. No reason to keep the extra bytes.
- Screenshots and UI — lossless or quality 85+
- Sharp edges and text reveal compression at lower settings. Use lossless WebP for exact screenshots, or quality 85+ if lossless files are still too big.
- Logos with transparency — lossless
- Lossy compression can cause colour fringing around transparent edges. Lossless WebP avoids that and is still 20–35% smaller than a PNG.
- Hero and product images — quality 75–82
- Large above-the-fold images need to load fast. Quality 75–82 saves 30–50% over quality 85 and the difference is invisible unless you compare crops side by side.
- Animated WebP — quality 60–75
- Each frame is compressed separately. Going from quality 85 to 68 across a 30-frame animation roughly halves the file size with very little visible change in motion.
Why image size matters for page speed
The biggest visible element on most pages — usually a hero image — is what Google measures for Largest Contentful Paint (LCP). Cutting that image from 180KB to 90KB on a typical connection saves real load time. Combined with lazy loading and CDN caching, getting your images smaller is often the single most effective thing you can do for your Core Web Vitals score.
