Two formats built forty years apart
WebP arrived in 2010 carrying ideas from video compression: frames that describe only what changed since the last one, and an encoder allowed to discard detail nobody will notice. GIF was finalised in 1989 and stores each frame as an indexed image drawn from at most 256 colours.
Converting an animated webp to gif therefore means giving up efficiency in exchange for reach. Expect the file to grow several times over, and expect smooth gradients to show banding that was not there before. Neither is a fault in the conversion; both are what the older format is.
What the tool does about the colour limit
The naive approach is to map every frame onto a fixed palette, which is why converted GIFs so often look muddy. Here the palette is computed from your own frames first and then applied, so the 256 slots are spent on the colours your image actually contains. Dithering smooths the boundaries that remain.
Two controls matter. Frame rate decides how many frames are kept, and dropping from 25 to 15 usually costs very little visually while cutting the file substantially. Output width matters even more, because GIF size scales with the pixel count and not much else; 480 pixels is a sensible default for anything going into a chat window or a document.
When GIF is still the right answer
The honest case for this conversion is that the destination is not yours to change. Older forums, email clients, some internal wikis, e-readers and a surprising number of corporate tools show a broken image where a WebP should be. A GIF works in an ordinary image tag with no video element, no autoplay policy and no support question attached.
If the destination does accept modern formats, an MP4 will look better than either at a fraction of the size, and there is a video-to-GIF page here for the opposite direction. Everything runs in your browser: files up to 500 MB are accepted, nothing reaches a server, and the engine is fetched once and cached.