Recompress modern web imagery carefully
WebP supports efficient lossy encoding and transparency. This route accepts WebP only, redraws one decoded still image, and writes WebP with a chosen quality preset. It does not preserve animation or original container metadata through that pixel pipeline.
Preset choices
Quality retains more texture at 86%; Smart uses 66%; Extreme uses 44% and is more likely to soften fine detail. Encoder output varies with image content and browser implementation.
Useful checks
- Start with the unedited source WebP.
- Inspect transparent edges, text, gradients, and repeated patterns.
- Test the download in the browsers or publishing system that will serve it.
Compatibility and alternatives
Current browsers generally handle WebP, but a legacy workflow may require JPG or PNG. That is conversion, not compression. Use Image Converter and choose the target based on transparency, animation, and quality needs.
WebP compression questions
Which WebP quality settings are used?
Quality uses 86%, Smart uses 66%, and Extreme uses 44% in the browser encoder. These settings are not promised size reductions.
Is WebP always smaller after recompression?
No. The source may already use efficient settings. FiloTool returns the original when the new result is not smaller.
Does this preserve WebP animation?
No guarantee is made for animation. The browser image element and Canvas pipeline produce a still WebP result rather than an animated sequence.
Will transparency remain?
WebP Canvas output can retain alpha transparency. Always inspect edge pixels because browser codec behavior can vary.
Why might WebP fail in an older browser?
The browser must decode the source and encode WebP through Canvas. Older or restricted browsers may lack one of those capabilities.