WebP to GIF
Turn a WebP into a GIF in this tab. A still WebP becomes a one-frame GIF; an animated WebP keeps every frame and its own delay. GIF has three hard limits: 256 colours per frame, one transparent colour, and delays in hundredths of a second. This page reports which of them your file actually hits.
Drop a WebP here
or choose a file · still or animated · one at a time · up to 100 MB and 400 frames · or paste with Ctrl + V
One WebP at a time · up to 400 frames and 100 MB · 256 colours per frame · per-frame delays from the file, rounded to 1/100 s · no upload · no account · no watermark
WebP to GIF: Three Ceilings, and Which One Your File Hits
A WebP can hold 16,777,216 colours, 256 levels of transparency per pixel, and a separate delay on every frame. A GIF can hold 256 colours per frame, one transparent colour, and delays made of whole hundredths of a second. Converting between them is not a repackaging job. Three axes get clipped, and the bill lands on whichever one your file was using.
The four test files behind the numbers below are a 1,600 × 1,200 photographic gradient, a 1,440 × 900 interface screenshot, a 24-frame clip with uneven delays, and a 30-frame clip timed at 17 ms per frame. Everything ran in Chrome 156, in the tab. Scores for animated clips are measured on the first frame, and unless a run says otherwise the settings were 256 colours, dither on and a white matte.
The short version: a flat screenshot came through pixel-exact, a photograph paid in colour, a soft-alpha logo paid at its edges, and a 58 fps animation paid 90 ms of its 510 ms.
How to convert a WebP to GIF here
- Add the file. Drop a WebP into the box above, or paste one with Ctrl + V. Still and animated files both work, one at a time, up to 100 MB and 400 frames.
- Set the width. The number field and the slider move together. The output is never wider than the source and stops at 1,600 px.
- Set the palette. Colours runs from 2 to 256 per frame. Dither mixes neighbouring entries to hide banding; the background menu decides what happens to transparency.
- Download. The result card reports the pixel size, frame count, playback length and file size, and the preview is the GIF itself, so it loops the way the file will.
Every change re-encodes on its own. There is no Run button.
What each control changes. Width sets output pixels; height follows the source aspect ratio. Colours sets the size of each frame's palette, which also sets the size of its colour table in the file. Dither trades bytes for smoother gradients. Loop forever writes the Netscape loop block; with it off, the GIF plays once. The background menu offers white, black, a custom colour, or 1-bit transparency, and the transparent option costs one palette slot out of the 256.
Colour is a table, and every frame carries its own
The 1,600 × 1,200 photograph arrived as a 26,018-byte lossy WebP. Written at 720 × 540 with 256 colours and dither on, the GIF is 164,366 bytes, 6.3 times the source, and scores 41.9 dB against the browser's own decode of the same frame. At 480 × 360 it is 79,989 bytes; at the full 1,600 × 1,200 it is 764,045 bytes. Bytes track pixels almost exactly: 0.42 per pixel at 720 px wide, 0.40 at full size.
That is the ceiling working as designed. A GIF frame is an index into a table of at most 256 colours, and the table travels with the frame. At 256 colours each table is 768 bytes. The 24-frame test clip therefore spends 18,432 bytes on palettes alone, 2.7% of its 681,082-byte file, before a single pixel is compressed. Dropping the palette to 64 colours with dither still on gives 443,546 bytes, 35% smaller. Turning dither off as well gives 110,858 bytes, 84% below the default, and the first-frame score barely moves: 54.4 dB with dither at 64 colours, 54.9 without.
Dither is the other half of the colour bill, and it is not free. The same photograph at 720 px, 256 colours, without dither: 54,965 bytes and 46.0 dB. With dither: 164,366 bytes and 41.9 dB. The dither pattern is high-frequency noise, and LZW cannot compress noise. It looks smoother to the eye because it breaks up banding, but it triples the file and lowers the pixel score. On a photograph, leaving it off is usually the better trade; on a gradient with visible steps, it is the only thing that helps.
There is a case where the palette costs nothing at all. The 1,440 × 900 interface screenshot is a 626-byte lossless WebP with a small number of flat colours. Its GIF is 12,737 bytes, 20 times the source, and every one of the 1,296,000 pixels matches the browser's decode exactly: maximum channel difference 0, score capped at 99 dB. The GIF is larger only because it stores a palette index per pixel (one byte at 256 colours) before compression, while the WebP codes repeated patterns across the whole image. When the palette already covers the image, conversion is lossless in the only sense that matters.
Transparency survives as one index, not a channel
The alpha test file is an 800 × 800 disc with a smooth radial fade, 45,582 bytes as a lossless WebP. It holds all 256 alpha levels: 141,275 pixels fully clear, 498,724 partially clear, and exactly one pixel fully opaque at the centre.
A GIF has no alpha channel. It has one palette entry that a frame can declare transparent, and every other entry is solid. This tool applies a fixed cutoff at 128: a source pixel below that becomes the transparent index, and a pixel at or above it becomes solid colour. The result on this file: 515,307 pixels transparent, 124,693 opaque, and two distinct alpha values where the source had 256. Of the 498,724 soft pixels, 374,032 landed on the transparent side and 124,692 on the solid side. The edge is a staircase, and no setting on this page can make it anything else.
Which side of the cutoff a pixel lands on changes the file more than it changes the picture. Exported with 1-bit transparency, the GIF is 59,023 bytes. Exported on a white matte, the same pixels take 175,488 bytes, three times as much, because every soft edge becomes a solid pale colour that has to be encoded. Among the pixels that survive as opaque, the transparent export scores 50.5 dB with a largest channel difference of 16 levels.
A WebP whose alpha is all 255 is unaffected: the palette simply never uses its transparent slot. And a GIF can still be pasted onto any background, because the transparent index is real, not a colour that happens to match the page.
The clock is a whole number of hundredths
GIF stores each frame's delay as an integer number of hundredths of a second, and browsers treat anything below 2 as 10. So the format's practical ceiling is 50 frames per second, and every delay lands on a 10 ms grid.
The 24-frame clip tests the grid in both directions. Its frames are timed at 40 ms, 80 ms, 120 ms and 200 ms; the GIF writes 4, 8, 12 and 20 hundredths. All 24 delays sum to 1,560 ms, the same as the source, with no drift. Uneven timing survives as long as each frame is a multiple of 10 ms.
The 30-frame clip is not so lucky. Its frames are 17 ms apart, roughly 58 fps. Rounded to the grid, every frame becomes 2 hundredths, so 30 frames that took 510 ms now take 600 ms. The animation plays 17.6% slower, and the only choice is how to lose the difference: this tool rounds each frame on its own, which keeps the average as close as the format allows. A 60 fps source cannot be stored as 60 fps in a GIF at all; 50 fps is the ceiling.
Frame count is capped at 400, and the encode runs one frame at a time in the tab. The 24-frame 480 × 270 clip takes 0.69 s; the 60-frame 640 × 360 clip takes 2.29 s and produces 2,474,260 bytes. Each frame is a full redraw: a GIF has no way to say "same as the frame before", so there is no inter-frame prediction to lean on.
What the file size follows
Three levers, measured on the same clip and the same photograph:
| Change | Result | Effect |
|---|---|---|
| Photo, 720 → 480 px at 256 colours | 164,366 → 79,989 B | −51%, pixels fall 56% |
| Photo, 720 → 1,600 px | 164,366 → 764,045 B | ×4.6, pixels ×4.9 |
| 24-frame clip, 256 → 64 colours, dither on | 681,082 → 443,546 B | −35% |
| 24-frame clip, dither off at 64 colours | 443,546 → 110,858 B | −75% |
| 24-frame clip at 320 px | 681,082 → 337,322 B | −50%, 44% of the pixels |
Width is the strongest lever because bytes follow pixels almost linearly. The palette is the second: it changes both the table size and how well LZW can find repeats. Dither is the third, and it can double or triple a photograph for a gain the eye may like and the score does not.
For a GIF that has to fit a size limit: cut the width first, then the colours, then turn dither off. A 24-frame 480 × 270 clip at 64 colours without dither is 110,858 bytes, a sixth of the 681,082-byte default.
What the GIF does not carry
Metadata is left behind. A WebP can carry an ICC profile in its container; a GIF has no ICC slot, no Exif block and no XMP. The pixels arrive as 8-bit sRGB values and that is all that gets written. If colour accuracy matters, convert to PNG instead.
A palette is not a quality setting. There is no quality slider because GIF has no transform stage to tune. The only decisions are pixel count, palette size, dither and transparency.
Animated frames become full frames. A WebP animation can store each frame as a rectangle smaller than the canvas, with its own offset. The browser's decoder hands back full frames, and this tool redraws the whole canvas for each one. The output is correct; it is also why a small, efficient WebP can turn into a large GIF.
The loop count is copied, not invented. An animation marked as looping forever in the WebP gets the Netscape loop block in the GIF. With Loop forever unchecked, the block is omitted and the GIF plays once.
The file is written by this page. There is no encoder library and no server: the palette, the LZW stream, the frame blocks and the trailer are assembled in JavaScript, and the bytes go straight into a Blob.
Why the file never leaves the tab
The WebP is read from disk by the browser, decoded by the browser's own image decoder, drawn to a canvas and encoded by the page. There is no upload endpoint in the code, and no request carries the file.
You can check that without trusting this page. Open DevTools, switch to Network, clear the list, then change a setting. The re-encode produces no new request: the page's resource list stayed at 7 entries across a full re-encode in the test. Load the page, cut the network, and conversion still works: the same 800 × 800 alpha file produced a 59,023-byte GIF offline, byte-identical to the online run.
Quick answers
Why is my GIF bigger than the WebP? Because a GIF stores a palette index per pixel (one byte at 256 colours) before compression, while a WebP predicts and transforms. A 26,018-byte photograph became a 164,366-byte GIF at 720 px, and a 32,442-byte 24-frame clip became 681,082 bytes. Flat art is the exception: the 626-byte screenshot became a 12,737-byte GIF with every pixel unchanged.
Why did only the first frame come through? Some browsers expose an animated WebP as a single image rather than a list of frames. This page uses the browser's frame decoder; where that decoder is missing, it converts frame 1 and says so in the status line. Chrome and Edge expose the frames.
Why does my animation play slower after conversion? GIF delays are whole hundredths of a second with a 2/100 s floor. A 17 ms frame becomes 20 ms, so 30 frames stretched from 510 ms to 600 ms in the test here. Anything above 50 fps cannot be stored without slowing it down.
Why did the soft edges of my logo turn jagged? GIF transparency is one palette index, so a pixel is either clear or solid. An 800 × 800 fade with 498,724 semi-transparent pixels came out with two alpha values and a stepped edge. The white-matte export hides the steps on a white page but triples the file size.
Why is my photo grainy after converting? Dither is on by default. It breaks banding by mixing palette entries, which adds high-frequency noise that LZW cannot compress. On the test photograph it tripled the file, 54,965 to 164,366 bytes, and lowered the score from 46.0 to 41.9 dB. Turn it off for photos.
Can I keep a transparent background? Yes, as one transparent colour. Choose Keep transparency (1-bit) in the background menu. Soft edges become hard, and the export is usually much smaller than a matte: 59,023 bytes against 175,488 on the alpha test.
Does this work offline, and is anything uploaded? Nothing is uploaded. The page has no server component for the conversion, and a run with the network disconnected produced the same bytes as the online run.