Photos to GIF

Cost scales with area, so size the frame first

Every frame stores pixels, so halving the width and height of a GIF removes roughly three quarters of its data. No other setting comes close, which makes dimensions the first thing to decide rather than the last.

For a UI demonstration 320-480 pixels wide is usually enough, since the result is typically displayed inline at around that size anyway. Exporting at full screen width and letting the page scale it down means paying for pixels nobody sees.

The palette is where the quality goes

A GIF frame can hold 256 colours. Everything else is approximated, and that approximation — not the compression, which is lossless — is what makes GIFs look coarse compared to the source.

Content with a narrow range of colours survives this well: screen recordings, line art, flat illustration. Photographic content with gradients does not, because a sky reduced to a handful of blues becomes visible bands.

Why dithering can make the file bigger

Dithering hides banding by scattering pixels of the available colours so the eye blends them. It works, and it fights the compression directly: the algorithm shrinks files by finding repeated runs of pixels, and dithering deliberately replaces smooth areas with high-frequency noise that has no runs to find.

So the banding fix and the file-size goal pull in opposite directions. On flat-coloured content, turning dithering off entirely is often both smaller and cleaner.

Frame rate and duration

GIF timing is stored per frame in hundredths of a second, and most viewers clamp very short delays, so extremely high frame rates do not play as intended anyway.

• 10-15 fps looks fine for screen recordings and interface demos.
• Trim to the seconds that carry the point — duration costs linearly.
• A static camera compresses far better than a panning one; crop to the moving region.
• If the clip is longer than about five seconds, consider whether it should be a video.