Video to GIF

Making a GIF without handing over the footage

GIFs get made from material people have not decided to publish yet: a moment from a private recording, a bug reproduced in an internal tool, a clip from footage still under embargo, something from a family video that is going into a group chat and nowhere else. Uploading the source video to a website in order to get a few seconds of it back is a strange trade, and most GIF makers ask you to make it.

This one does not. FFmpeg compiled to WebAssembly runs in your browser, reads the video from your own disk and writes the GIF back. The footage never becomes part of a network request, so the material you have not published stays unpublished.

What GIF costs you, and it is a lot

GIF is a format from 1987 and converting to it is a genuine downgrade in two specific ways that no tool can avoid. First, colour: GIF holds at most 256 colours per frame, so gradients, skin tones and sunsets get quantised to a palette and band visibly. Flat graphics, screen recordings, cartoons and UI captures survive far better than filmed footage does.

Second, size. GIF stores each frame almost independently, while a video codec stores mostly the differences between frames. That is why a few seconds of video routinely produces a GIF several times larger than the clip it came from. Keep the clip short, in the region of a few seconds, or the file becomes a problem for whoever has to load it.

When you should not make a GIF at all

Worth saying on a page whose whole job is making GIFs: most of the time a short muted looping video is better in every measurable way. It is smaller, sharper, keeps full colour, and every modern platform plays it automatically. Where GIF still wins is destinations that accept an image and not a video: some email clients, some documentation systems, older forums, internal wikis, and anywhere a file is going to be embedded as an image. That is the case this tool is for.

If the destination will take a video, use one. If it will not, keep the clip short, prefer flat graphics and screen recordings over filmed footage, and expect the file to be larger than the video was.

The first run, and where it stops

The first conversion downloads a single WebAssembly build of FFmpeg, about 30 MB, served from this domain and cached afterwards. It is fetched only when you convert. After that, memory is the limit rather than time: the video is decoded inside the browser tab, so a long or high resolution source can exhaust it. Short clips, which are what GIF wants anyway, are comfortable almost anywhere.

How long can the video be?

Short clips work best. GIF files grow quickly with length, so a few seconds is ideal.

Is anything uploaded?

No. The clip is converted on your device and never sent to a server.

Why is my GIF so much larger than the video?

Because GIF is a format from 1987 that stores each frame separately with almost no compression between frames, while a video codec stores mostly the differences. A few seconds of video can easily produce a GIF several times larger than the clip it came from. That is the format, not the conversion.

Why do the colours look wrong?

GIF holds at most 256 colours per frame, so anything with gradients, skin tones or a sunset gets quantised down to a palette and banding appears. Flat graphics, screen recordings and cartoons survive far better than filmed footage.

How long a clip should I convert?

Short. A few seconds is where GIF works. Beyond that the file size grows fast enough to be a problem for whoever has to load it, and a video file is almost always the better answer.

Is my video uploaded to make the GIF?

No. The engine runs inside your browser, so the file stays on your device. You can verify that by going offline and converting anyway.

Should I use a GIF at all?

Often not, and it is worth saying. Modern platforms handle a short muted looping video better than GIF in every respect: smaller, sharper, full colour. GIF still wins where the destination only accepts an image, which is why this tool exists.