Why a Three-Second GIF Outweighs the Video It Came From

A format from 1989 that never learned about motion

The GIF89a specification describes an animation as a sequence of images with a delay between them. That is the whole model. There is no notion of a scene that persists, no vector telling the decoder that this block of pixels is the one from the last frame moved eleven pixels to the left. Modern video codecs spend almost all their cleverness on exactly that idea, and it is where almost all of their compression comes from: in a talking-head clip, the wall behind the head is transmitted once and then referred to for the next three hundred frames. A GIF has no way to refer to anything.

There is one crude exception, and it is worth knowing because it explains why some GIFs behave much better than the arithmetic predicts. A frame may be written as a smaller rectangle placed at an offset, and pixels that did not change since the previous frame may be marked transparent instead of stored. FFmpeg — the engine this tool runs — enables both of those by default. On a screen recording where a cursor moves across a still window, this is enormous: most of each frame collapses to nothing. On footage from a camera, where sensor noise means practically every pixel differs slightly from the last, it saves almost nothing. That single distinction is why the same settings can produce a 300 kB GIF from a screen capture and a 5 MB GIF from a hand-held phone clip.

The arithmetic, and where the one soft number lives

Bytes ≈ width × height × frames × b ÷ 8. Everything on the right is exact except b, the number of bits each pixel costs after LZW has done its work. Before compression each pixel is one index into a table of up to 256 colours, so it starts at 8 bits. LZW on dithered photographic content usually gets that down to somewhere between 2 and 5, which is why the honest thing to do is take b = 3 for a first estimate and accept that the answer is good to roughly a factor of two. That sounds sloppy until you notice it is the same factor of two you would get from guessing a video bitrate, and it is enough to tell you whether you are one setting away from your limit or four.

One thing the tool does not do is measure the colours in your clip. A high-quality GIF pipeline runs two passes: one to build a palette from the actual pixels present, a second to map the frames onto it. This tool runs a single pass, so the 256 slots are filled from a generic table rather than from your footage. The visible consequence is banding in skies, gradients and skin tones, and a slight coarseness in dark areas. The invisible consequence is on size, and it cuts both ways: a generic palette dithers more, and dithering adds high-frequency noise that LZW hates, which pushes b upward. If your clip has few colours to begin with — a logo animation, a chart, a terminal window — none of this bites, and your file will come out far below the estimate.

The width box is not a size box

You type a width; the tool computes the height from the clip's shape. For a 16:9 landscape clip, 480 gives you 480 × 270 — 129 600 pixels a frame. For a phone clip held upright, the same 480 gives you 480 × 853, which is 409 440 pixels a frame: more than three times as many, for the same number typed into the same box. This is the single most common reason a GIF comes out unexpectedly enormous, and it is invisible in the interface because the interface only shows you one of the two dimensions.

The fix is one line of arithmetic. If you want a portrait clip to weigh what a 480-wide landscape clip weighs, ask for 270 wide: 270 × 480 is exactly 129 600 pixels again. More generally, decide on a pixel budget per frame rather than on a width. Something in the region of 120 000 to 150 000 pixels a frame is comfortable for a chat window at any shape — that is 480 × 270 landscape, 270 × 480 portrait, or 360 × 360 square — and then you only have the frame rate and the duration left to argue about.

The frame rate you asked for is probably not the one you got

This one is pure format archaeology and it catches everybody. The GIF89a specification stores the pause before the next frame in hundredths of a second — the field, in its own words, "specifies the number of hundredths (1/100) of a second to wait". There is no finer unit and no fractional one. So a frame rate is only reproducible if 100 divides evenly by it. Within the range this tool offers, that means 2, 4, 5, 10, 20 and 25 frames per second, and nothing else.

The default of 12 is not one of them. A twelfth of a second is 8.33 hundredths, and the file can only hold 8 or 9 — that is 12.5 or 11.1 frames per second in playback, so your eight-second clip runs for 7.68 or 8.64 seconds. Nobody watching a cat GIF will notice. Somebody watching a countdown, a metronome, a lap timer or a screen recording where you are demonstrating a timing bug absolutely will. Thirty is worse: a thirtieth of a second is 3.33 hundredths, the file holds 3, and playback comes out at 33.3 frames per second — eleven percent fast. If timing matters, pick 10, 20 or 25 and the file plays at the rate you asked for.

When the right answer is not a GIF

Video size is a different formula and a much friendlier one: bytes = bitrate × seconds ÷ 8. Eight seconds at 800 kbit/s is 800 kB, and 800 kbit/s buys you a perfectly watchable clip at full resolution and thirty frames per second. That is almost six times smaller than the GIF built from the same eight seconds at a fifth of the resolution and a third of the frame rate — and the video has sound, if you want it. Every messaging app, every modern forum, every issue tracker and every social network plays MP4 and WebM inline and loops them on demand. The autoplaying loop that people call "a GIF" on the web today is, nine times out of ten, a silent MP4.

So keep the GIF for the cases where nothing else is accepted, and there are real ones: a wiki or ticketing system that only takes image attachments, an email client that will not embed video, an old forum whose editor has an image button and nothing else, a README rendered somewhere that strips video tags. In those places a GIF is not a nostalgic choice, it is the only moving picture that will survive the trip. Everywhere else, converting to a GIF means paying five to ten times the bytes to lose the sound, most of the colours and half the frames.

Two small things about this particular tool

It always starts at second zero. The duration box is a ceiling on the output, not a window you can slide, so the eight seconds you get are the first eight seconds of the file. If the moment you want is at 0:42, cut the clip with the trim tool first and feed the cut piece in. This is not a limitation you can work around with a bigger duration: setting the maximum to 30 gives you the first thirty seconds and a GIF nobody can post anywhere.

And the size it reports is measured in units of 1 048 576 bytes while calling them MB. That is a mebibyte wearing a megabyte's label, a very old and very common piece of sloppiness. It matters here only in one place: a limit expressed as 10 000 000 bytes is 9.54 of the tool's "MB", so a file the tool proudly calls 10.0 MB is over that limit by nearly half a megabyte. When you are aiming at a hard ceiling, aim five percent under it and stop thinking about the units.

Frequently asked questions

Can I get more than 256 colours into a GIF?

Across the whole file, yes; within one frame, no. The specification allows each image block to carry its own local colour table, so a twenty-frame animation could in principle use twenty different palettes and touch several thousand distinct colours overall. But every individual frame is still limited to 256, and a local table costs up to 768 bytes each time it changes. In practice this buys you very little on video, because the eye compares neighbouring frames and a palette that shifts between them produces visible flicker. The bigger win available to a GIF encoder is not more colours but better-chosen ones — a palette measured from your actual footage rather than a generic table.

My GIF is still too big and I have already cut the width. What now?

Cut the duration next, then the frame rate, in that order. Duration and frame rate are both linear in the frame count, so they buy the same reduction per unit — but a shorter clip is almost always a better clip, whereas a lower frame rate is a visible degradation below about 8 frames per second, where motion starts to read as a slideshow. Two seconds at 10 frames per second is twenty frames, and twenty frames of 320 × 180 at 3 bits is 432 kB. If even that is too big, the honest conclusion is that the clip's content does not compress: check whether it is camera footage with a moving background, and if it is, either crop tightly to the part that matters or accept that this needs to be a video.

Does the GIF keep the sound?

No, and it never can: the format has no audio track and no place to put one. This is worth saying out loud because it is a silent failure — nothing warns you, the conversion succeeds, and you discover it when you post a clip whose whole point was a line of dialogue. If the sound is what you wanted to share, the answer is a video, or the audio on its own: this site has a tool that pulls the soundtrack out of a video file as MP3, AAC or WAV without touching the picture.

Why does my GIF look grainy in the dark parts when the video looked fine?

Because 256 colours have to cover the whole range from black to white, and in a dark scene most of your image is crowded into a handful of them. The encoder covers the gap by dithering — scattering pixels of two available colours to fake a third — and in flat dark areas that scatter reads as grain. It also costs you size, because dithering is high-frequency noise and high-frequency noise is exactly what LZW cannot compress. Two things help: brighten or crop the clip before converting so less of it lives in the crushed region, and prefer content with flat, distinct colours. Nothing fixes it entirely inside the format, which is one more reason the answer is often a video.

Does the video leave my computer while this runs?

No. The conversion runs in the page, in a build of FFmpeg compiled to WebAssembly, and the engine itself is served from this site rather than from a third-party network — so not even the one-off download of the engine hands your address to anyone else. There is one visible consequence you should expect: the first conversion of a session downloads roughly 32 MB of engine and takes a while, and every conversion after that starts immediately. And there is one test that settles the claim without trusting it: load the page, turn off your network, and convert a clip. If it still works, nothing was uploaded.