How to Make an Animated GIF: From a Video Clip or a Photo Burst

From video: the video-to-GIF tools load an MP4, WebM or MOV, let you pick the window of seconds you want, and sample frames out of it at your chosen rate. The browser decodes the video itself — WebM plays natively everywhere, MP4 (H.264) plays in every consumer browser, and MOV works when it carries the same mainstream codecs. The clip never leaves the device, which matters because source clips are often screen recordings of things that were never meant to be seen by a stranger's server.

From stills: the image-to-GIF tool takes a set of frames — a burst photo, animation cels, screenshots of a UI state — and assembles them into an animation with one shared delay. This is the older use of GIF and still the reliable one: because you supplied the frames, timing is exact, and there is no video decoder guessing at sampling.

Dimensions first. GIF is paletted and uncompressed per frame except for simple LZW, so bytes scale with pixel count and change count — halving the width cuts frame area by four. A reaction GIF does not need 720p; 320-480 px wide is the format's natural size, and on a phone screen nobody can tell.

Frame rate second. Video thinks in 24-60 fps; GIF lives happily at 10-15. Motion at 12 fps looks identical to 24 in anything under a second of movement because the frames you dropped were interpolating a blink. Every frame you delete is bytes the encoder never sees.

Duration third, and most important: three seconds. A GIF that loops a perfect cycle needs no more; a five-second clip at 15 fps is 75 frames, and seventy-five frames of photographic content is how 15 MB GIFs happen. Pick the loop's beginning and end deliberately — a GIF whose motion starts and stops at the same place reads infinite, and readers watch infinite GIFs three or four times, which is the entire economy of the format.

GIF stores each frame against a palette of at most 256 colours — not 24-bit truecolour. Photographic frames therefore get either dithering (tiny checkerboards of nearby colours that blend at viewing distance — grainy but smooth in tone) or banding (visible steps in gradients — skies go stripy). Neither is a bug in the tool; both are the format doing what it can.

The practical consequences: GIF is brilliant for screen recordings, UI demos, logos, flat illustration and anything with hard edges and few colours, where 256 is plenty and LZW compresses the flat areas almost for free. It is mediocre for film footage and terrible for skies over landscapes. If your subject is photographic and the destination is the web, consider what the modern alternatives actually offer: animated WebP carries true colour at a fifth of the weight, and APNG carries full alpha — but neither survives being pasted into an email signature or a twenty-year-old forum, which is precisely why you are making a GIF.

GIF transparency is one binary flag per pixel, chosen from the palette: a pixel is either background or not. There is no semi-transparent edge, so a feathered cutout pasted onto a GIF frame shows a halo of its original matte. The workflow fix: composite frames against the destination background colour before assembly, so the edge is already correct for where the GIF will live.

Looping is a metadata flag — forever or a set count — and different platforms disagree about defaults. Some chat apps strip loop settings; a forum may play once. If the animation's meaning completes in one cycle, set it to loop forever and accept the rare one-shot viewer; if it is a reaction beat, a single clean pass often reads better anyway.

The assembly order for video sources: trim to the loop window, choose dimensions and rate, and only then export — every re-encode of a GIF loses a little because its frames were already palettised once. Make one GIF from the source video rather than making a GIF of a GIF.

Chat apps impose 1-8 MB ceilings, Discord's is 10 for non-nitro, email gateways choke past 20 MB total, and a page that inlines six 5 MB GIFs will never pass a Core Web Vitals audit. The rescue order is always: fewer frames (drop to 8 fps), smaller frame (320 px wide), shorter loop (2 s instead of 4). That trio halves bytes at each step and the result still reads as the same idea.

If the destination is a website rather than a chat, the honest answer is probably not a GIF at all: a muted, looping, autoplaying WebM or MP4 carries true colour and alpha at a fraction of the weight, and browsers handle it well. GIF's remaining kingdom is paste-ability — the format that works everywhere without anyone approving it — and for that, small and slightly crude is not a compromise; it is the job description.