Is my video uploaded when I make a GIF?

No. The conversion runs inside the same browser tab that loaded this page using FFmpeg WebAssembly. Your video file is read into memory locally, processed locally, and the GIF is offered for download from your own device. Nothing is uploaded to a server.

Why does the GIF look better than other converters I have tried?

Because we use a two-pass palette pipeline. The first pass analyses the video and builds a 256-colour palette tailored to its content. The second pass re-encodes the clip through that palette with dithering. Single-pass GIF encoders use a generic palette, which produces banding and washed-out colours.

Why is the GIF still much larger than the source MP4?

GIF is an old format with limited compression — 256 colours per frame, no inter-frame motion prediction, no audio. For any clip longer than a few seconds, GIF will be larger than the equivalent MP4 at the same quality. If file size matters more than autoplay-in-any-context behaviour, MP4 or WebP is the better target.

What is the maximum file size?

There is no imposed limit. The practical ceiling is your browser memory — the source video and the GIF both need to fit in RAM during conversion. Multi-gigabyte sources are possible if you have the headroom, but most useful GIFs come from short clips, so this rarely matters.

Which frame rate should I pick?

15 fps is the right default for most clips — high enough for fluid motion, low enough to keep file size sensible. Drop to 10 fps for screen recordings and slideshows; push to 24 fps when motion is critical and file size is not. Going above 24 fps in a GIF usually wastes bytes that the format cannot encode efficiently.

Which dithering option should I use?

Bayer dithering produces smaller files with a slightly visible cross-hatch pattern in flat areas. Sierra2-4A produces smoother gradients but slightly larger files. None gives you posterised blocks of colour — useful for pixel art, terrible for live footage. When in doubt, leave it on Bayer.

Does the conversion work on iPhone?

Safari has historically limited the WebAssembly features FFmpeg.wasm uses, so iPhone results vary. Short clips often work; longer or higher-resolution clips may stall. Chrome and Firefox on Android handle the same workloads reliably. On desktop, all three modern browsers work.

// Tools / Video → GIF

Video to GIF Converter

Drop a video clip, pick a frame rate and width, get back a GIF. Two-pass palette generation for visibly better colour than the browser-based competition. Your file never leaves the browser — conversion runs inside this tab using FFmpeg WebAssembly.

// Video → GIF

LOADING ENGINE

Initialising…

// Long read
What this tool does, in detailA practical guide to making a GIF that does not look like it was made in 2003. Why browser-based conversion works, when GIF is the right format and when it is not, how the two-pass palette pipeline actually improves the output, and what the trade-offs around file size and quality look like in practice.
How browser-based GIF conversion worksThe conversion you just ran — or are about to run — happens entirely inside this browser tab. There is no upload step, no server-side processing queue, and no "please wait while we encode your file" intermission. When you drop a video on the tool above, the browser reads the file into memory using the standard File API, hands the bytes to a WebAssembly build of FFmpeg, and waits for FFmpeg to do its job. The GIF that comes out is offered to you as a blob URL — your browser generates a download from data it already has, not from a server it had to ask.
The piece that makes this possible is FFmpeg.wasm: the FFmpeg C codebase compiled with Emscripten into a WebAssembly module that modern browsers can execute at roughly fifty to eighty percent of native speed. The binary is about thirty megabytes, which the browser downloads once on first visit and then caches indefinitely. From the second visit onwards, the engine is already on your machine — the only thing that takes time is the actual encoding work.
The headers required to make this work (cross-origin isolation, so the browser will give the page access to SharedArrayBuffer) are set across this whole site. If you want a deeper look at what FFmpeg is doing under the hood, the post on how FFmpeg works walks through the architecture.
When to use GIF vs MP4 vs WebP for short clipsThe honest answer is that GIF is almost never the format you want, and you should pick it anyway when its specific quirks happen to match what you need. Here is the rough decision tree.
Use GIF when:the clip needs to autoplay and loop silently inside a context that does not support video — Slack, some email clients, certain CMS image fields, GitHub READMEs, Markdown renderers, older messaging apps. GIF's entire reason for still existing is that it is treated as an image by tools that refuse to treat actual video as anything. If you are pasting into Slack and you want it to play, you want a GIF.
Use MP4 when: any video player will be involved. MP4 with H.264 video is universally supported, includes audio, and for the same visual quality produces files anywhere from five to fifty times smaller than the equivalent GIF. Twitter, Reddit, Discord, Bluesky and most modern platforms now silently convert uploaded GIFs into MP4 on the server anyway — sending them an MP4 directly skips the round trip. If your destination accepts video, send video. The main converter on this site handles MP4 in both directions.
Use WebP when:the destination is a modern web surface — a blog post, a product page, a content-managed image slot — and you want animation with much better compression than GIF can offer. Animated WebP supports a full 24-bit colour palette instead of GIF's 256, supports alpha transparency cleanly, and typically produces files thirty to fifty percent smaller than a comparable GIF. Support is now universal in modern browsers. The main reason people still pick GIF over WebP is that some downstream tools — old chat clients, certain email clients — still do not handle WebP, and they all handle GIF.
The realistic split: GIF for chat and embed contexts that demand it, MP4 for everything else, WebP when you control the playback environment and want quality.
Why two-pass palette generation produces better-looking GIFsGIF is a palette format. Every pixel in a GIF frame is an index into a colour table of at most 256 entries. That is the entire reason GIF files exist, and it is also why naïve GIF conversion looks bad.
When a single-pass converter writes a GIF, it has to guess which 256 colours to keep. Most pick a generic web-safe palette — the same 216 or 256 colours regardless of whether the source is a sunset, a code screenshot, or a cat. The result is the visible banding you have seen in low-quality GIFs forever: smooth gradients turn into stair steps, skin tones drift, deep reds end up oddly orange. The colours in the GIF are not the colours in the source, because the source colours were not on the palette the encoder was working from.
Two-pass palette generation fixes this. On the first pass, FFmpeg watches the entire clip and computes a 256-colour palette specifically optimised for that clip's content — thepalettegenfilter. A clip that is mostly sky gets a palette heavy on blues. A clip of someone's face gets a palette heavy on skin tones. On the second pass, thepaletteuse filter re-encodes the clip through that custom palette, optionally with dithering to break up remaining banding. The output uses the same 256 colours per frame as a single-pass GIF would, but they are 256 colours that actually appear in your video. That is the difference.
The dithering option in the controls above is the third lever. Dithering scatters small pattern noise across regions where the chosen palette cannot represent the source colour exactly, so the eye averages it into roughly the right colour. Bayer dithering uses a fixed pattern — small files, faintly visible cross-hatch in flat areas. Sierra2-4A is an error-diffusion algorithm — slightly bigger files, smoother gradients. none turns dithering off, which produces blocky posterised regions everywhere the palette cannot quite match. Bayer is the default here because the trade-off it makes is the right one for the kinds of clips most people convert.
File size vs quality trade-offsThere are four levers that control the size of a GIF, in roughly decreasing order of impact: duration, resolution, frame rate, and dithering choice. Knowing how each one moves the number is the fastest way to get the size you want without ruining the clip.
Duration is linear. A four-second GIF is twice the size of a two-second GIF at the same settings. There is no compression trick that changes this — GIF stores frames mostly independently. If your output is too large, the single most effective thing you can do is trim. The start-time and duration controls above are there precisely so you can encode the eight interesting seconds of a two-minute clip without paying for the rest.
Resolution is roughly quadratic in width, because halving width also halves height (the tool keeps your aspect ratio). A 960-pixel-wide GIF is around four times the file size of a 480-pixel-wide GIF from the same source. For most embed contexts — chat threads, blog posts, README files — 480 pixels is plenty. For a small inline preview, 320 is often enough. Going above 720 in a GIF is rarely worth what it costs in bytes.
Frame rate is also roughly linear, but with a ceiling. A 30 fps GIF stores twice as many frames as a 15 fps GIF of the same duration, but because GIF has no motion prediction between frames, much of that extra data is redundant. 15 fps is the sweet spot for most live-action footage; 10 fps is fine for screen recordings and slideshows. Going above 24 fps in a GIF is almost always wasted — the format cannot exploit the extra information.
Dithering is a smaller lever. Switching from Sierra2-4A to Bayer typically saves five to fifteen percent. Switching from Bayer to no dithering saves a bit more, at the cost of obvious posterisation. If file size matters and the source is flat-colour (a screen recording, a vector animation), no dithering can actually look fine.
The honest practical advice: trim aggressively, keep width at or below 480 unless you need detail, hold frame rate at 15, leave dithering on Bayer. If the output is still too big, the source clip is probably the wrong choice for GIF — convert to MP4 instead.
Frequently asked questionsIs anything sent to a server during conversion?No. You can verify this in your browser's developer tools: open the Network tab before you click Convert, run the conversion, and confirm that no outbound request carries your file. The FFmpeg binary is fetched once on first visit and cached; nothing else leaves your machine.
Why is the first conversion slow but later ones are fast?The first visit downloads the thirty-megabyte FFmpeg WebAssembly binary. Every subsequent visit uses the cached copy and starts instantly. The conversion itself is bounded by your CPU and by the length and resolution of the clip — short clips at 480 pixels usually finish in seconds.
Which input formats does the tool accept?Anything FFmpeg can read, which is effectively any video format you are likely to have: MP4, MOV, MKV, WebM, AVI, M4V, 3GP, FLV, and dozens more. The tool does not care about the wrapper — it cares about whether the codec inside is one FFmpeg understands, which it almost always is.
Can I make a transparent GIF?GIF technically supports a single transparent colour. The pipeline here does not attempt to detect transparency from video, because video sources almost never have it. If you need real alpha transparency in an animation, use WebP — it supports proper alpha channels and is widely supported in modern browsers.
Why does my GIF have audio missing?GIF has no audio. It is a strictly silent format. If audio matters, you want MP4, which you can produce on the main converter page.
Is there a length limit?Not a hard one, but a practical one. A clip much longer than fifteen or twenty seconds in GIF will almost certainly be larger than the contexts you want to embed it in will tolerate. The trim controls are the right answer — pick the section that matters and encode that.
Can I see the FFmpeg command this tool runs?Yes. The log panel that appears during conversion is the same output FFmpeg produces when you run it from a terminal — argument string, filter graph, frame counts. If you want to reproduce the same result on the command line, the arguments are visible there. For more on how the engine works, see how FFmpeg works.
Where do I find other browser-based tools like this one?On the tools hub. The main MP4 / MKV / MOV converter lives on the homepage; new tools land at /tools as they ship.

// Tools / Video → GIF

Video to GIF Converter

// Video → GIF

LOADING ENGINE

Initialising…

// Long read
What this tool does, in detailA practical guide to making a GIF that does not look like it was made in 2003. Why browser-based conversion works, when GIF is the right format and when it is not, how the two-pass palette pipeline actually improves the output, and what the trade-offs around file size and quality look like in practice.
How browser-based GIF conversion worksThe conversion you just ran — or are about to run — happens entirely inside this browser tab. There is no upload step, no server-side processing queue, and no "please wait while we encode your file" intermission. When you drop a video on the tool above, the browser reads the file into memory using the standard File API, hands the bytes to a WebAssembly build of FFmpeg, and waits for FFmpeg to do its job. The GIF that comes out is offered to you as a blob URL — your browser generates a download from data it already has, not from a server it had to ask.
The piece that makes this possible is FFmpeg.wasm: the FFmpeg C codebase compiled with Emscripten into a WebAssembly module that modern browsers can execute at roughly fifty to eighty percent of native speed. The binary is about thirty megabytes, which the browser downloads once on first visit and then caches indefinitely. From the second visit onwards, the engine is already on your machine — the only thing that takes time is the actual encoding work.
The headers required to make this work (cross-origin isolation, so the browser will give the page access to SharedArrayBuffer) are set across this whole site. If you want a deeper look at what FFmpeg is doing under the hood, the post on how FFmpeg works walks through the architecture.
When to use GIF vs MP4 vs WebP for short clipsThe honest answer is that GIF is almost never the format you want, and you should pick it anyway when its specific quirks happen to match what you need. Here is the rough decision tree.
Use GIF when:the clip needs to autoplay and loop silently inside a context that does not support video — Slack, some email clients, certain CMS image fields, GitHub READMEs, Markdown renderers, older messaging apps. GIF's entire reason for still existing is that it is treated as an image by tools that refuse to treat actual video as anything. If you are pasting into Slack and you want it to play, you want a GIF.
Use MP4 when: any video player will be involved. MP4 with H.264 video is universally supported, includes audio, and for the same visual quality produces files anywhere from five to fifty times smaller than the equivalent GIF. Twitter, Reddit, Discord, Bluesky and most modern platforms now silently convert uploaded GIFs into MP4 on the server anyway — sending them an MP4 directly skips the round trip. If your destination accepts video, send video. The main converter on this site handles MP4 in both directions.
Use WebP when:the destination is a modern web surface — a blog post, a product page, a content-managed image slot — and you want animation with much better compression than GIF can offer. Animated WebP supports a full 24-bit colour palette instead of GIF's 256, supports alpha transparency cleanly, and typically produces files thirty to fifty percent smaller than a comparable GIF. Support is now universal in modern browsers. The main reason people still pick GIF over WebP is that some downstream tools — old chat clients, certain email clients — still do not handle WebP, and they all handle GIF.
The realistic split: GIF for chat and embed contexts that demand it, MP4 for everything else, WebP when you control the playback environment and want quality.
Why two-pass palette generation produces better-looking GIFsGIF is a palette format. Every pixel in a GIF frame is an index into a colour table of at most 256 entries. That is the entire reason GIF files exist, and it is also why naïve GIF conversion looks bad.
When a single-pass converter writes a GIF, it has to guess which 256 colours to keep. Most pick a generic web-safe palette — the same 216 or 256 colours regardless of whether the source is a sunset, a code screenshot, or a cat. The result is the visible banding you have seen in low-quality GIFs forever: smooth gradients turn into stair steps, skin tones drift, deep reds end up oddly orange. The colours in the GIF are not the colours in the source, because the source colours were not on the palette the encoder was working from.
Two-pass palette generation fixes this. On the first pass, FFmpeg watches the entire clip and computes a 256-colour palette specifically optimised for that clip's content — thepalettegenfilter. A clip that is mostly sky gets a palette heavy on blues. A clip of someone's face gets a palette heavy on skin tones. On the second pass, thepaletteuse filter re-encodes the clip through that custom palette, optionally with dithering to break up remaining banding. The output uses the same 256 colours per frame as a single-pass GIF would, but they are 256 colours that actually appear in your video. That is the difference.
The dithering option in the controls above is the third lever. Dithering scatters small pattern noise across regions where the chosen palette cannot represent the source colour exactly, so the eye averages it into roughly the right colour. Bayer dithering uses a fixed pattern — small files, faintly visible cross-hatch in flat areas. Sierra2-4A is an error-diffusion algorithm — slightly bigger files, smoother gradients. none turns dithering off, which produces blocky posterised regions everywhere the palette cannot quite match. Bayer is the default here because the trade-off it makes is the right one for the kinds of clips most people convert.
File size vs quality trade-offsThere are four levers that control the size of a GIF, in roughly decreasing order of impact: duration, resolution, frame rate, and dithering choice. Knowing how each one moves the number is the fastest way to get the size you want without ruining the clip.
Duration is linear. A four-second GIF is twice the size of a two-second GIF at the same settings. There is no compression trick that changes this — GIF stores frames mostly independently. If your output is too large, the single most effective thing you can do is trim. The start-time and duration controls above are there precisely so you can encode the eight interesting seconds of a two-minute clip without paying for the rest.
Resolution is roughly quadratic in width, because halving width also halves height (the tool keeps your aspect ratio). A 960-pixel-wide GIF is around four times the file size of a 480-pixel-wide GIF from the same source. For most embed contexts — chat threads, blog posts, README files — 480 pixels is plenty. For a small inline preview, 320 is often enough. Going above 720 in a GIF is rarely worth what it costs in bytes.
Frame rate is also roughly linear, but with a ceiling. A 30 fps GIF stores twice as many frames as a 15 fps GIF of the same duration, but because GIF has no motion prediction between frames, much of that extra data is redundant. 15 fps is the sweet spot for most live-action footage; 10 fps is fine for screen recordings and slideshows. Going above 24 fps in a GIF is almost always wasted — the format cannot exploit the extra information.
Dithering is a smaller lever. Switching from Sierra2-4A to Bayer typically saves five to fifteen percent. Switching from Bayer to no dithering saves a bit more, at the cost of obvious posterisation. If file size matters and the source is flat-colour (a screen recording, a vector animation), no dithering can actually look fine.
The honest practical advice: trim aggressively, keep width at or below 480 unless you need detail, hold frame rate at 15, leave dithering on Bayer. If the output is still too big, the source clip is probably the wrong choice for GIF — convert to MP4 instead.
Frequently asked questionsIs anything sent to a server during conversion?No. You can verify this in your browser's developer tools: open the Network tab before you click Convert, run the conversion, and confirm that no outbound request carries your file. The FFmpeg binary is fetched once on first visit and cached; nothing else leaves your machine.
Why is the first conversion slow but later ones are fast?The first visit downloads the thirty-megabyte FFmpeg WebAssembly binary. Every subsequent visit uses the cached copy and starts instantly. The conversion itself is bounded by your CPU and by the length and resolution of the clip — short clips at 480 pixels usually finish in seconds.
Which input formats does the tool accept?Anything FFmpeg can read, which is effectively any video format you are likely to have: MP4, MOV, MKV, WebM, AVI, M4V, 3GP, FLV, and dozens more. The tool does not care about the wrapper — it cares about whether the codec inside is one FFmpeg understands, which it almost always is.
Can I make a transparent GIF?GIF technically supports a single transparent colour. The pipeline here does not attempt to detect transparency from video, because video sources almost never have it. If you need real alpha transparency in an animation, use WebP — it supports proper alpha channels and is widely supported in modern browsers.
Why does my GIF have audio missing?GIF has no audio. It is a strictly silent format. If audio matters, you want MP4, which you can produce on the main converter page.
Is there a length limit?Not a hard one, but a practical one. A clip much longer than fifteen or twenty seconds in GIF will almost certainly be larger than the contexts you want to embed it in will tolerate. The trim controls are the right answer — pick the section that matters and encode that.
Can I see the FFmpeg command this tool runs?Yes. The log panel that appears during conversion is the same output FFmpeg produces when you run it from a terminal — argument string, filter graph, frame counts. If you want to reproduce the same result on the command line, the arguments are visible there. For more on how the engine works, see how FFmpeg works.
Where do I find other browser-based tools like this one?On the tools hub. The main MP4 / MKV / MOV converter lives on the homepage; new tools land at /tools as they ship.