Resize a WebP Image
Drop a WebP here and a WebP comes back at the new size — the tool never switches formats on you. Both flavours of the format decode fine, lossy and lossless alike, and transparency passes through the resample untouched. Two things are worth understanding before you start: the quality slider quietly decides which flavour you get back, and animated WebP files lose their animation with no warning at all. Both are covered below.
The slider picks lossy or lossless — quietly
Your output is written by the browser's own WebP encoder, and the quality slider is the only instruction it receives. In Chromium-based browsers, 100 on that slider produces a losslessly encoded file; any lower value produces a lossy one. The default is 90, which means a lossless WebP resized with default settings comes back lossy.
Whether that matters depends on the image. A photograph will not show the difference and will be dramatically smaller as lossy. A flat-colour illustration, a logo with fine edges, or anything you intend to keep editing deserves the slider at 100 so the encode stays exact. A source that was already lossy gains nothing from 100 — the first encode's damage is in the pixels — but it does avoid adding a second round.
Animated WebP is flattened, and nothing warns you
This tool resizes stills. When an animated file arrives, only its first frame is decoded and resized; every other frame is discarded. For animated GIFs the tool reads the file structure, notices the extra frames and puts a notice on the result card. No equivalent check exists for WebP — an animated WebP goes in, a motionless single-frame WebP comes out, and the interface says nothing.
So the failure is silent, and worth guarding against yourself: if a WebP came from a sticker, a screen recording or a converted GIF, play it before resizing and inspect the output after. To resize an animation and keep it moving, use software built for animation — export the frames, scale them, and reassemble.
Where the resized file will and won't work
Compatibility is a solved problem in browsers: every current engine — Chrome, Safari, Firefox, Edge — has decoded WebP for years, so a resized file is safe anywhere on the web. Google's published comparisons put lossy WebP roughly 25 to 34% smaller than equivalent JPEGs, and lossless WebP around 26% smaller than PNG, which is why the format is worth keeping when the destination allows it.
The holdouts are outside the browser: older desktop image viewers, some corporate upload forms, and printing workflows can still refuse the extension. When you hit one, resize here first and change the container with the image converter afterwards — the pixels are already right, so the conversion is the only remaining step, and the resample count stays at one.
Frequently Asked Questions
Can this turn my WebP into a JPG while resizing?
No — there is no output-format option anywhere in this tool; the format that goes in is the format that comes out. Do the resize, then hand the file to the image converter for the container change.
Why did my animated WebP stop moving?
Because only the first frame is decoded and resized; the rest are discarded, and unlike with GIFs, no notice is shown for WebP. If the animation matters, this is the wrong tool for that file.
Is the transparency safe in a lossy WebP?
Yes — the format encodes the alpha plane separately from the colour data, and it stays clean through a lossy save, so cut-out edges hold up even when the surrounding colours are compressed.
The resized WebP is bigger than my original. Why?
Your source was probably encoded harder than the slider's 90, or you enlarged the image. Either lower the quality, or let the compressor squeeze bytes out at unchanged dimensions.
Does any metadata survive the resize?
No — the result is rebuilt from the decoded pixels, so EXIF and colour profiles are left behind. Keep the source file if you need what its header carried.