Why a GIF costs twenty times what a video costs

Why the same three seconds is 4MB as a GIF and 180KB as a video

GIF was finalised in 1989. It has three properties that make it unsuitable for the job it is most often used for, and all three follow from that date.

256 colours, chosen from a palette, per frame. The format stores an index into a colour table, not a colour. Anything with a gradient, a soft shadow, film grain or skin tone has to be quantised down and then dithered, which is why GIFs of real footage look speckled and banded. The dithering also destroys the compressor’s job, because dither noise is by definition unpredictable.

One bit of transparency. A pixel is either fully opaque or fully transparent. There is no partial alpha, so an anti-aliased edge over an unknown background gets a hard, jagged fringe in whatever colour the file was matted against. This is the “why does my logo have a white halo” problem, and it cannot be fixed in GIF.

No motion compensation. Modern video codecs describe a frame as “the previous frame, with this block moved 14 pixels left”. GIF can only say “these pixels changed”: a rectangular difference region, compressed with LZW. Pan the camera and every pixel changes, so every frame is stored nearly in full.

Put together: a 640×360 three-second clip that an H.264 encoder stores in about 180KB will commonly be 3 to 6MB as a GIF, and will look worse. That is a factor of twenty to thirty, paid on every page load, by every visitor.

Replace it with a video element

The replacement is a muted, looping, inline video. Autoplay is permitted by every modern browser under the same conditions: the video must be muted and, on iOS, carry playsinline.

<video autoplay loop muted playsinline
       poster="/motion/preview.jpg"
       width="640" height="360">
  <source src="/motion/demo.webm" type="video/webm">
  <source src="/motion/demo.mp4"  type="video/mp4">
</video>

Two sources because VP9 in WebM is usually 20 to 40 per cent smaller than H.264 at the same quality and Safari’s support has historically lagged; the MP4 is the guaranteed fallback. Always set width and height, or the page will shift when the video loads.

Three things this buys you beyond size: the user can pause it, you can respect reduced motion by not autoplaying, and the browser will not decode it while it is off-screen if you add preload="none" and start it when it scrolls into view.

If you are stuck with GIF

Sometimes the destination demands it: an email client, a chat platform, a forum that strips video tags. The quality difference between a careless GIF and a careful one is large, and it comes down to the palette.

The default in most converters is a single palette computed from one frame. The better approach generates a palette from the whole clip, then applies it with dithering:

ffmpeg -i in.mp4 -vf "fps=15,scale=480:-1:flags=lanczos,palettegen=stats_mode=diff" palette.png
ffmpeg -i in.mp4 -i palette.png -lavfi "fps=15,scale=480:-1:flags=lanczos,paletteuse=dither=bayer:bayer_scale=3" out.gif

stats_mode=diff weights the palette toward the parts of the frame that move, which is where the eye is. Bayer dithering produces a regular pattern that LZW compresses far better than the default error-diffusion dither, usually cutting the file by a third for a small visible cost.

The other two levers, in order of effect: drop the frame rate to 12 to 15, and drop the resolution. Both cut size roughly linearly. Trimming a second off the clip is worth more than any encoder setting.

The middle options

Between GIF and video there are two raster formats worth knowing.

Animated WebP: full 8-bit alpha, far better compression than GIF, supported everywhere that matters now. Typically 30 to 50 per cent of the GIF size at better quality. It is the correct answer when you need an animated image: something that works in an <img> tag, as a CSS background, or anywhere a video element is not allowed.

APNG: full alpha, lossless, and very large. Useful when you need exact pixels and transparency and size is not a concern, which is rare.

Both are images, so neither can be paused by the user and neither honours reduced motion on its own. That is a real accessibility cost and the reason a video element is preferable where it is allowed.

The free path

ffmpeg does all of it (the conversion, the palette work, the WebP and APNG output, the frame-rate and scale changes) and it is the tool the paid converters are usually wrapping. Gifski is an open-source encoder that produces noticeably better GIFs than the default by using a per-frame palette and a smarter quantiser, at the cost of speed. ImageMagick handles APNG assembly. None of this needs a licence.

The limitation

GIF persists for a reason that has nothing to do with quality: it is universally accepted. Email clients, older forums, messaging apps and some content management systems will take a GIF and nothing else, and a technically superior file that the destination rejects is worth nothing.

So the honest advice is not “never use GIF”. It is: never use GIF on a web page you control, always use it where the destination demands it, and when you do, spend the two minutes on the palette because the difference is visible and the file is often a third of the size.