filetity

WEBP -> GIF · Local tool

WebP to GIF

Turn a WebP into a GIF, frames and all, for somewhere that will not take WebP.

Last updated

  1. 01 / Your device

    the file stays here

  2. 02 / Browser memory

    the work runs locally

  3. 03 / Back to you

    saved on this device

When you would use this

Situations, not settings.

An uploader that rejects WebP
Older forum software, some CMS uploaders and plenty of internal tools accept GIF and nothing newer. The animation survives the trip.
An animation for an email signature
Mail clients have never agreed on WebP and most still will not play it. GIF is the one animated format they all render.
A slide deck that needs the loop
PowerPoint and Keynote play a GIF on a slide. Dropping in a WebP gets you a still frame or nothing at all.

How it works / no cloud

A conversion engine, not an upload form.

An animated WebP is read frame by frame with the browser's own ImageDecoder, which hands back each frame already composited onto the full canvas, and the frames are written into a GIF by the same encoder /video-to-gif uses. Frame timing is converted by cumulative position rather than one frame at a time, so a long animation does not drift, and the loop count carries across because 0 means forever in both formats. Nothing is uploaded and no conversion engine is downloaded.

  • Offline ready
  • Installable app
  • No file limit queue

Straight answers

No accordion. Nothing hidden.

Is it free?
Yes, with no watermark and no page limit.
Does it need an account?
No. There is no account system.
Is my file processed on my device?
Yes. The file is read by your browser and never uploaded. There is no server to send it to.
What formats are supported?
WebP in, animated or still. GIF out, animated if the source was.
What are the limits?
GIF holds 256 colours per frame, so a photographic animation loses colour depth that WebP kept, and the GIF is usually several times larger. Very long or very large animations are refused before decoding rather than exhausting memory, with the size and frame count named so you can resize and retry. A browser without ImageDecoder is told it cannot do this rather than handed the first frame.
Does it work on mobile?
Yes, on any modern mobile browser. Large files are limited by the memory the phone gives the browser.
Does it work offline?
Yes. Nothing is downloaded to make this work, so it keeps working with no network connection once the page has loaded.
Does the animation survive, or do I get one frame?
The animation survives. Every frame is read, composited and written into the GIF with its own delay, and the loop count carries over. This is the part most converters get wrong: drawing a WebP onto a canvas gives you the first frame only, and a tool that does that hands back a still image with a .gif extension. If this page cannot read the frames, on a browser without ImageDecoder, it refuses and says so rather than giving you that still.
Why is the GIF so much bigger than the WebP?
Because GIF is a format from 1989 and WebP is not. GIF stores at most 256 colours per frame and compresses with LZW; WebP uses the same techniques as modern video. A photographic animation can easily come out several times larger as a GIF and with visible banding in gradients. That is the cost of a format everything accepts.
What happens to a still WebP?
It becomes a one frame GIF, which is a valid GIF and what a still image can be. If the destination accepts PNG or JPG, either is a better file than a still GIF at every size, and the image converter will make one.
Why would anyone want a GIF in 2026?
Because somewhere still will not take anything else. Older chat clients, some forum software, email signatures, a few CMS uploaders and plenty of internal tools accept GIF and reject WebP. That is the whole reason this page exists: not because GIF is good, but because it is accepted.
Does it slow down or drop frames?
It keeps the length and can drop a frame. GIF measures delays in hundredths of a second and every browser silently replays anything under 2 of those at 10, so a 60 frames a second WebP cannot stay 60 in a GIF whatever a tool claims. Frames whose share rounds below that floor are merged into the one before them, which keeps the total running time exactly right rather than letting it drift.

Keep working locally

7 available · more coming