High quality GIF from video

The numbers, before the reasoning

Why a 480px GIF beats a 1080px one

This is the claim people push back on hardest, so here is the mechanism. A GIF frame is an array of indexes into a palette of at most 256 colours. That ceiling does not move when the frame gets bigger. A 480x270 frame has 129,600 pixels sharing 256 colours. A 1920x1080 frame has 2,073,600 pixels sharing the same 256.

At 480px, each palette entry covers around 500 pixels and can be tuned to a narrow band of the image. At 1080p it covers 8,000, so entries get stretched across regions that genuinely differ, and you see banding in skies, blotches on skin and mud where there was shadow detail. The larger GIF has more pixels and worse colour, and colour is what the eye reads as quality at the size a GIF is usually viewed.

The exception is text. If the GIF is a screen recording where someone has to read a label, width is the only thing that helps, and 640 to 960px is justified. Raise the colour count at the same time, because UI colour is flat and compresses well.

One pass versus two pass palettes

The naive way to write a GIF is to use a fixed palette, usually the 216 colour web safe table or a 3:3:2 bit split of the RGB cube. It is fast, it needs no analysis, and it is what a lot of converters still do because it means they can stream the output.

Two pass does something different:

1. Pass one reads the clip and builds a paletteEvery frame is sampled and a 256 colour palette is computed from the colours that are actually present. A clip of a forest gets 256 greens. A clip of a spreadsheet gets greys and one blue.
2. Pass two encodes against that paletteEach pixel is mapped to its nearest entry, with dithering applied to hide the gaps. Because the palette was built for this clip, the gaps are small.

The stats mode matters too. Building the palette from the differences between frames rather than from whole frames concentrates the palette on the parts that move, which is where a viewer is looking. That is the mode used here, and it is why the indicator on the converter panel says two pass palette: on rather than hiding it.

The equivalent on the command line, if you would rather run it yourself:

ffmpeg -ss 3 -t 8 -i input.mp4 \
  -vf "fps=15,scale=480:-2:flags=lanczos,palettegen=max_colors=256:stats_mode=diff" \
  -y palette.png

ffmpeg -ss 3 -t 8 -i input.mp4 -i palette.png \
  -filter_complex "[0:v]fps=15,scale=480:-2:flags=lanczos[v];[v][1:v]paletteuse=dither=sierra2_4a:diff_mode=rectangle" \
  -loop 0 -y output.gif

That is the same pair of commands the tool on this site runs, compiled to WebAssembly so it happens in your browser rather than on your machine or ours.

Dithering, and when it hurts

Dithering scatters pixels of two available colours to fake a third the palette does not have. It converts banding into noise, and the eye forgives noise far more readily than it forgives a hard edge across a gradient.

• Sierra2 4a. Error diffusion. The best looking option on photographic content. It carries quantisation error forward to neighbouring pixels, so gradients stay smooth. On detailed footage it measured about a third more bytes than Bayer, because the scattered pixels break up the runs LZW relies on. On flat content it goes the other way and comes out cheaper, because it leaves flat areas alone.
• Bayer. An ordered pattern. Visibly regular if you look closely. It repeats, which does help on detailed footage, where it measured the cheapest of the three. On flat screen content it is the most expensive of the three by some distance, roughly double Sierra2 4a, because the pattern is applied to areas that had nothing in them to dither.
• None. Nearest colour, hard edges. Smallest of the three on flat content, where it measured under half of Bayer, and roughly Bayer's equal on detail. Correct for logos, line art, screen recordings and anything already limited to a handful of colours, where dithering only adds noise to an image that had none.

A useful test: if the clip has a sky, a face or a lighting gradient, use Sierra2 4a. If it is a screen, turn dithering off. Bayer is the one to reach for when you have detailed footage and the file has to come down.

The order to change things when the file is too big

Quality settings and size settings are the same settings, so there is a right order to walk them down. From least to most visible damage:

1. Shorten the clip. Free, and usually improves it.
2. Drop the colour count from 256 to 128. Rarely visible on anything.
3. Change the dithering. On detailed footage, Sierra2 4a to Bayer saved about a quarter. On flat screen content it is the reverse: turning dithering off saved about half against Bayer.
4. Drop the frame rate from 20 to 15, or 15 to 10.
5. Reduce the width, in steps of 80 pixels.
6. Drop the colour count below 64. Now you will see it.

The GIF compressor walks exactly this ladder when you give it a target size, and the video to gif converter shows what each step does to the estimate before you commit to an encode.

Honest limits

There is a point past which GIF cannot be made good, and it is worth knowing where it is. A 30 second clip of handheld outdoor footage at 720px will never be both small and clean, because every frame differs from the last and the palette has to cover a whole scene. No converter, no compressor and no model changes that.

When you hit it, the answer is a different format. Animated WebP is roughly a third the size at full colour, and a muted MP4 or WebM is smaller still and autoplays like a GIF everywhere it is allowed. The output menu on the converter writes WebP directly. Use GIF when the destination genuinely requires it, not out of habit.

Quality questions