Video to GIF, Explained

After reading this you will understand what a GIF can and cannot store, why a two-pass palette makes the colors look better, and how frame rate, width and duration trade off against file size so you can produce a small, sharp clip.

The reverse tool exists for a reason: GIF is a poor general video format. But it plays inline everywhere, loops without a player, and needs no audio track. That makes it the right choice for a short reaction clip, a UI walkthrough of three seconds, or a looping demo in a bug report. This tool takes a slice of a video and rebuilds it as an animated GIF, entirely in your browser.

What a GIF actually is

A GIF is a sequence of frames, each drawn from a palette of at most 256 colors. That limit is the single fact that explains almost everything about GIF quality and size. A single frame of typical video uses 24-bit color, which is 2^{24} = 16{,}777{,}216 possible colors. GIF must throw away all but 256 of them.

Each frame also stores its pixels with lossless LZW compression. There is no motion prediction between frames, unlike H.264 or VP9, so a GIF cannot reuse most of the previous frame the way a real video codec does. That is why doubling the duration roughly doubles the file size, and why real video at the same visual quality is often 10 to 30 times smaller.

When to use it, and when not to

Use a GIF when the clip is short (under about 10 seconds), has no important audio, and must autoplay and loop in a context that will not run a video player: a chat message, a README, a forum post. Keep the motion simple. Flat colors and small regions of change compress well.

Do not use a GIF for anything longer than 10 seconds, anything with gradients or film grain, or anything where sound matters. A 20-second clip at full width can easily exceed 50 MB. If you need audio, use Extract Audio from Video for the sound and keep the video as video. If you already have a GIF and want it small, convert it with GIF to MP4.

Why two passes for the palette

The 256-color limit forces a choice: which 256 colors? A single-pass encoder guesses a generic palette before it has seen the frames. A two-pass encoder does better. On the first pass it scans every frame and builds a histogram of the colors that actually appear. On the second pass it maps each pixel to the nearest palette entry it chose.

The visible difference is largest on content with a narrow color range. A clip of a blue sky and green grass wastes most of a generic palette on colors that never appear. A palette built from the clip itself can spend all 256 slots on the blues and greens that are present, so banding in the sky drops sharply.

The size formula and its intuition

You cannot predict GIF size exactly because LZW compression depends on the content. But an upper bound before compression is easy and useful for setting expectations.

Here B_{raw} is the raw indexed-pixel count in bytes (one byte per pixel, since each pixel is a palette index), w and h are width and height in pixels, f is frames per second, and d is duration in seconds. The height follows from the width and the source aspect ratio, so you control it indirectly.

The finished GIF is smaller than B_{raw} after LZW, often by a factor of 2 to 5 on simple content and much less on noisy content. The point of the formula is the shape of the dependence: size scales linearly with each of width times height, frame rate, and duration. Halving the width cuts w \times h by four, because height falls with it. That is the biggest lever you have.

A worked example using the defaults

Reading the result and picking settings

Judge the output on three things: file size, smoothness of motion, and color fidelity. Each maps to a control. Size follows the formula above. Smoothness follows frame rate: 10 fps looks slightly choppy on fast pans but is fine for slow motion or UI clicks; 15 fps looks smooth enough for most sharing and doubles nothing you care about. Color follows the palette, which the two-pass step handles for you.

The table shows how the same 3-second, 16:9 clip behaves as you change the two levers you control directly.

Common mistakes

The most frequent error is leaving the width at the source resolution. A 1920 px source at 3 seconds and 12 fps has a raw size of 1920 \times 1080 \times 12 \times 3 = 74{,}649{,}600 bytes, about 74.6 MB raw. No amount of palette tuning saves that. Set a width you actually need, usually 320 to 480 px.

The second is pushing frame rate up to hide choppiness that comes from the source, not the GIF. If the original is 24 fps, exporting at 30 fps invents nothing; it just duplicates frames and inflates size. Match or go below the source rate.

The third is expecting clean gradients. A sunset sky has thousands of near-identical blues that 256 colors cannot represent, so you will see banding no matter what. For such content, a real video is the honest answer.

Related tools

To convert a finished GIF back into a compact video, use GIF to MP4; an MP4 of the same clip is usually a fraction of the GIF size. To pull the soundtrack out of a video, use Extract Audio from Video. To change audio formats on their own, use the Audio Format Converter.

Related tools

Audio Format Converter

Convert between WAV, MP3, OGG, FLAC, M4A and more.

Extract Audio from Video

Rip the audio track of a video to MP3, WAV or FLAC.

GIF to MP4

Convert an animated GIF into a small MP4 video.

Audio Trimmer

Cut a section out of an audio file, with fades.

Chord Identifier

Name any chord from notes you pick or type.

Euclidean Rhythm Generator

Generate world-music rhythms from two numbers.