WebP to GIF
Animated WebP in, animated GIF out — frame durations and all. The encoder is written into this page, so your file never leaves the device.
GIF stores every frame as its own picture, so width is the single biggest lever on file size. Halving the width quarters the pixels.
Why a converter has to write the GIF itself
Your browser will happily decode a WebP — that is how the format shows up on half the web. What it will not do is write a GIF. The canvas toBlob method supports PNG, JPEG and WebP, and nothing else. Every browser-based WebP to GIF converter therefore either ships a WebAssembly copy of ImageMagick, or uploads your file to a server, or writes a GIF encoder by hand. This page does the third one: palette selection, LZW compression and the GIF89a byte layout are all written out in about six hundred lines of JavaScript that ship with the page.
That is not showing off. It is the reason the animation survives, the reason nothing is uploaded, and the reason the tool starts working the instant the page loads instead of after a two-megabyte download.
Animated WebP, frame by frame
An animated WebP is a RIFF container holding an ANMF chunk per frame, each with its own duration. Reading them out needs ImageDecoder, part of the WebCodecs family, which Chrome, Edge and Opera support and Firefox and Safari currently do not. Where it exists we walk every frame and carry its real duration across into the GIF. Where it does not, your browser hands back a single still image — and rather than quietly giving you a one-frame GIF, the page reads the WebP container directly, notices the animation flag, and says so in the result row.
GIF measures frame delay in hundredths of a second, so a 60 fps WebP cannot be reproduced exactly. Delays under 0.02 s are also rewritten to 0.10 s by most browsers, a rule dating back to Netscape, so we clamp to 0.02 s rather than write a number that will be ignored. A fast animation will therefore come out slightly slower than the source. That is GIF, not the converter.
256 colours, and what happens to the other sixteen million
GIF allows 256 colours per frame. A WebP screenshot, a flat illustration or a sticker usually has fewer than that already, and the page checks: if every colour in a frame fits, they are used verbatim and the result is pixel-for-pixel identical to the source. The result row says colours kept exactly when that happens.
Photographs do not fit, so they are reduced with median cut — the colour cube is split repeatedly along its longest axis until there are as many boxes as colours allowed, and each box collapses to its weighted average. Turning on dithering scatters the rounding error into neighbouring pixels (Floyd–Steinberg), which hides banding in skies and gradients at the cost of a noisier, larger file. Flat artwork usually looks worse dithered; photographs usually look better.
Keeping the file from ballooning
A GIF stores whole frames, not video-style motion vectors, so a ten-second clip is ten seconds of individual pictures. Three things keep that under control here. Frames identical to the one before are dropped and their time added to the previous frame. Frames that differ only in part of the picture are written as just that rectangle, with unchanged pixels marked transparent so the previous frame shows through. And the width control matters more than anything else, because pixel count scales with the square of it.
Transparency is kept when you ask for it, using the restore to background disposal method so a shape that disappears actually disappears. That mode rules out the frame-differencing trick, so a transparent animation will be larger than an opaque one. Untick keep transparency and the frames are flattened onto white, differencing switches on, and the file usually drops by a third or more.
What this page will not do
It will not convert video. MP4 and WebM need a video decoder and a very different pipeline; this page only reads still and animated images. It will not turn a GIF back into WebP or MP4. It will not repair a truncated file. And it cannot read an animated AVIF beyond the first frame in most browsers, because AVIF animation support in ImageDecoder lags behind WebP.
Still WebP, PNG, JPEG and AVIF all convert fine — you get a single-frame GIF, which is occasionally exactly what an old forum or a wiki upload form wants.
Common questions
Does the animation survive?
Yes, in Chrome, Edge and Opera, which can decode animated WebP frame by frame. Firefox and Safari hand back only the first frame; when that happens the page detects the animation flag inside the WebP container and tells you in the result, rather than silently giving you a still.
Why is the GIF bigger than the WebP?
Because GIF is from 1989 and WebP is not. GIF stores every frame as a palette image with LZW compression and no motion prediction, so a file five to ten times larger is normal. Reducing the width is the fastest way to bring it down, followed by cutting the colours to 128 or 64.
Is the picture quality reduced?
Only if it has to be. If a frame uses 256 colours or fewer, those exact colours are used and the GIF is identical to the source pixel for pixel. Photographs have far more, so they are reduced with median cut and you can see the difference in smooth gradients.
What does the dither option actually do?
It spreads each pixel's rounding error into its neighbours, so a gradient that would otherwise show hard bands becomes a fine speckle instead. It helps on photographs and skies, hurts on flat illustrations and text, and always makes the file bigger because neighbouring pixels stop being identical.
My animation plays slower than the original.
GIF frame delays are whole hundredths of a second, and browsers rewrite anything under 0.02 s to 0.10 s. A WebP recorded at 50 or 60 frames per second cannot be represented, so it is clamped to 0.02 s per frame — about 50 fps at best.
Can it do video to GIF?
No. MP4 and WebM need a video decoder, which is a different job from reading an image container. This page handles still and animated images only.
Does transparency carry over?
Yes, but GIF transparency is one bit: a pixel is either fully see-through or fully opaque. Soft edges that were semi-transparent in the WebP become hard edges. Anything under 50% opacity is treated as transparent.
Is my file uploaded anywhere?
No. The decoding, the colour reduction and the GIF writing all happen in this page. You can disconnect from the network after the page loads and it still works.