Convert WebP to GIF with every frame intact

Why convert WebP to GIF when GIF is the worse format

It is worth being blunt about this, because the honest answer shapes every other decision on this page. GIF is older, holds fewer colors, compresses far less efficiently and cannot express a soft edge. WebP beats it on every measurement that exists. Nobody arrives here because they want a better file.

They arrive because something on the other end will not take a WebP. Email is the usual culprit: most mail clients either strip the image or render nothing, while an animated GIF has worked in them since before some of those clients were written. Then there are the older forums, the chat tools locked to a version from four years ago, the presentation software that opens the file dialog and refuses to list it, and the internal wiki that nobody has updated since the format was standardized. In every one of those cases the animation is the thing you are trying to keep and the format is the price of admission. That is the trade this page is built around, which is why it reports what the trade costs instead of quietly making it.

How the frames actually come out of an animated WebP

A WebP file is a RIFF container: a header, then a sequence of labeled blocks. An animated one carries an ANIM block with the loop count and then one ANMFblock per frame, each holding that frame's position on the canvas, its width and height, how long it should be shown, and whether it should be blended over what came before or replace that rectangle outright. Inside every ANMF sits an ordinary still image — the same VP8 or VP8L bitstream you would find in a normal .webp file.

That last detail is what makes this work everywhere. Each frame is lifted out, given its own container header, and handed to the browser as though it were a single-picture WebP, which every engine has been able to decode for years. The frames are then composited in order onto a canvas, honoring the blend and disposal rules the file specifies, so what reaches the encoder is a complete picture per frame rather than the difference rectangles the file actually stores. Getting that composition wrong is the classic failure mode here: it produces an animation where the moving part smears across the frame instead of moving, and it looks like a decoding bug rather than a bookkeeping one.

The alternative was the browser's own ImageDecoder, which does all of the above in about half the code. It was measured in both engines before a line of this was written, and it is missing from Safari entirely — building on it would have produced a converter that does nothing at all for a large share of visitors, and worse, a test suite unable to prove the animation path on the engine those visitors use. Reading the container ourselves costs a few hundred lines and works in every browser.

Two hundred and fifty-six colors, and what that actually looks like

A GIF frame is drawn from a lookup table with at most 256 entries. Your WebP has no such limit — a photographic frame routinely contains forty or fifty thousand distinct colors, and a gradient alone can spend several thousand. Every one of those has to be mapped to the nearest of 256 survivors.

Rather than describe that in the abstract, the panel counts the distinct colors in your actual file and puts the number next to the palette size, before you convert. Then the result plays beside the original at the same dimensions, so the banding is something you look at rather than something you take on faith. Flat graphics, logos, screen recordings and line art often survive with no visible difference at all, and can drop to 64 colors with none either. Skies, skin, shadows and anything with a gradient show it immediately. Dithering trades that banding for fine noise, which reads better to the eye and compresses worse, so it costs bytes — the receipt shows both numbers and you can run it twice.

Transparency stops being a matter of degree

WebP carries a genuine alpha channel: every pixel gets its own opacity from 0 to 255. GIF has a single palette entry that means invisible, and no way to say anything between that and fully solid. There is no setting to change this and no converter that handles it better, because it is what the format can express.

In practice that means any pixel more than half transparent vanishes and the rest turn opaque. Drop shadows lose their fade. Anti-aliased edges — the row of half-transparent pixels that makes a curve look smooth rather than stepped — become a hard jagged outline, often with a halo of whatever color the encoder guessed underneath. This is the single most common disappointment with this conversion, and the tool warns about it before running whenever it finds partly transparent pixels in your file, rather than letting you discover it afterwards. If transparency is what you need to keep and the animation is not, converting to PNG preserves the alpha channel exactly.

Your animation may have to slow down, and here is the arithmetic

Timing in GIF is measured in units of ten milliseconds. That granularity alone would be survivable, but there is a second rule on top of it: the value 1 is interpreted by every browser as though it were 10. The behavior dates to the mid-nineties, it is now baked into an enormous number of files, and no vendor will change it. Two units — twenty milliseconds — is consequently the smallest interval that means what it says, and 50 pictures per second is as fast as the format can honestly go.

WebP has no such constraint; its durations are plain milliseconds. So a source at 60 pictures per second has nowhere to land, and the conversion has to stretch it to 50. The total running time grows by a fifth, and this page works out the exact number of milliseconds and shows it in the panel before you commit to anything. Fractional remainders are accumulated across the sequence rather than resolved frame by frame, which keeps a long animation from finishing noticeably late — round each one on its own and a hundred frames can end up most of a second adrift.

Expect the GIF to be bigger — often several times bigger

The two formats disagree about what a frame is. To WebP, most frames are an edit applied to the previous picture, expressed with the same motion-oriented techniques that make modern video small. To GIF, a frame is a complete image in its own right; its one concession is that an untouched rectangle may be omitted and inherited from what was already on screen. Where the background holds still — a screen capture, a logo animation, a chart being drawn — that concession earns its keep, and the receipt counts how many frames it applied to. Where the entire picture is in motion it earns nothing.

Tripling in size is unremarkable and a tenfold increase is not rare. You get an estimate before conversion and a measured figure afterwards, next to the multiplier against your source file. When the output is too heavy to send, thinning the sequence is the cheapest correction available: keep every second frame and the discarded durations are folded into their neighbors, so the motion becomes coarser without speeding up. Reducing the width comes next. Beyond that,compressing the GIF to a target size works through colors, frames and resolution in that order and reports which levers it had to pull.

Where the work happens, and what this does not do

Two pieces of machinery are involved and neither of them is on a server. Your browser already contains a WebP decoder — it is how the file displays at all — and this page borrows it one frame at a time. The GIF encoder is our own code: median-cut quantization to build the palette, then the LZW compressor the format has used since 1987, both running on a background thread so the tab stays responsive while a long animation is written. Nothing about that path involves a network, which is why the work begins the instant you drop the file rather than after a queue.

There is no cropping, no rotation, no text, no reordering of frames and no speed adjustment beyond dropping frames. If your file turns out to be a single still image the tool says so plainly, because a GIF of a photograph is a strictly worse file than the WebP it came from and you should probablyconvert it to JPG instead. And if the destination will accept a video rather than an animated image,going from GIF to MP4 afterwards typically cuts the same animation by an order of magnitude.