$ man content-wiki/gif-creation-for-web

GIFs autoplay everywhere that video doesn't. LinkedIn autoplays GIFs in the feed with no click required. Email clients render GIFs (most video embeds get stripped). Slack previews them inline. Twitter/X treats them as native animations. The format is 30 years old and refuses to die because it solves a real problem: showing motion without requiring a video player, audio considerations, or user interaction. For product demos, feature announcements, tutorial snippets, and attention-grabbing feed content, a well-made GIF does the job in a format that works universally. The tradeoff: file size and color limitations. A GIF of a gradient-heavy UI can look terrible and weigh 15MB. A GIF of a clean screen recording with flat UI elements can be crisp and under 2MB. Knowing which situations favor GIF and which don't is the whole skill.

12-15 fps is the sweet spot for web GIFs. At 12 fps, motion is smooth enough that the human eye reads it as continuous animation rather than a slideshow. At 24 fps (film rate), file size roughly doubles without a perceptible quality improvement for most content types. The math: a 5-second GIF at 24 fps = 120 frames. At 12 fps = 60 frames. Half the data, nearly identical perceived smoothness for UI recordings and product demos. Dimensions matter more than frame rate for file size. A 800px wide GIF at 12 fps is often 3-4x larger than the same content at 480px. Most social platforms display GIFs at 400-600px wide anyway. Exporting at 480px width covers 90% of use cases without the file size penalty of higher resolution. Rule of thumb: target under 5MB for social media GIFs. Under 2MB is better. Over 5MB and platforms will recompress your GIF, which usually makes it look worse than if you'd optimized it yourself.

GIF supports a maximum of 256 colors per frame. This is not a suggestion, it's a hard technical constraint from the format specification. Where this bites you: - Gradients: a blue-to-purple gradient that looks smooth at 16 million colors becomes visibly banded at 256 colors. The GIF format tries to approximate the gradient by dithering (alternating pixels of different colors to simulate blending), but this adds noise and file size. - Photography and complex imagery: photographs have thousands of subtle color variations. Forcing them into 256 colors produces visible artifacts. - Shadows and transparency effects: most macOS UI shadows use semi-transparency over a variable background. GIF's 1-bit transparency (fully transparent or fully opaque, no in-between) makes shadows look harsh or disappear. Where this doesn't bite you: - Clean UI recordings with flat colors and minimal gradients - Terminal/code recordings (text is high contrast, limited palette) - Diagrams, flowcharts, and illustrations designed with flat colors Design GIFs with their format constraints in mind rather than recording something gradient-heavy and wondering why it looks bad.

For Mac: - Kap (free, open source): records your screen and exports directly to GIF, MP4, or WebM. The GIF export settings let you set frame rate and quality. Simple and reliable. The default settings are usually fine for quick social content. - LICEcap (free): older but still solid. Very small footprint. Records a region of your screen to GIF. No bells, no friction. For Windows: - ScreenToGif (free): screen recorder with a built-in editor. You can trim, add captions, adjust frame timing, and optimize before export. More features than you need for most use cases but good for precise control. For converting existing video to GIF: ffmpeg is the most reliable option. Two-step command that produces a properly optimized palette: # Step 1: generate color palette ffmpeg -i input.mp4 -vf "fps=12,scale=480:-1,palettegen" palette.png # Step 2: use palette to generate GIF ffmpeg -i input.mp4 -i palette.png -vf "fps=12,scale=480:-1,paletteuse" -loop 0 output.gif The two-step approach with a palette file produces significantly better color quality than the single-command version. Takes 10 extra seconds, worth it every time.

PRO TIP

Always optimize before deploying. gifsicle is a command-line tool that can reduce GIF file size by 30-60% without visible quality loss by removing redundant frame data and optimizing the color tables. Install on Mac: brew install gifsicle Basic optimization command: gifsicle -O3 --lossy=80 input.gif -o output.gif The -O3 flag applies the most aggressive lossless optimization (reorders frames for smaller delta). The --lossy=80 flag applies lossy compression similar to JPEG (80 is a good default, lower = smaller file but visible artifacts, higher = less savings). On a 10MB raw GIF this often produces a 4-6MB output with no visible quality difference. For batch optimization of a folder: for f in *.gif; do gifsicle -O3 --lossy=80 "$f" -o "${f%.gif}_opt.gif"; done Run gifsicle after exporting from any tool, before you upload anywhere. Platforms compress on top of whatever you give them, so starting smaller means ending up with a better result after their compression pass.

GIF: universal compatibility, large file size, limited colors. Use when you need it to work everywhere including email. MP4 (autoplay muted loop): 10-15x smaller than equivalent GIF, full color, but requires a video player and browser support for autoplay. Use for web pages where you control the embedding. Many builders use the pattern of displaying a looping muted MP4 instead of a GIF on their own site, then exporting actual GIFs specifically for social and email. Animated WebP: smaller than GIF, better color than GIF, but not supported in all email clients or older browsers. Use when you're confident in your audience's browser stack. The practical workflow for most builders: export MP4 from your recording tool, use it directly on your site (as a video element with autoplay muted loop), convert to GIF with ffmpeg when you need the format for social media or email, optimize the GIF with gifsicle before uploading. Frequently asked questions: Why does my GIF look great locally but terrible on LinkedIn? LinkedIn recompresses GIFs on upload. Starting with a well-optimized GIF (gifsicle) gives the platform better source material to work with. Also stay under 5MB ... larger files trigger more aggressive compression. Can GIFs have transparent backgrounds? Yes, but only 1-bit transparency. Pixels are either fully transparent or fully opaque. No feathered edges, no drop shadows with soft falloff. Design your GIF content with solid backgrounds if you need edge quality. What's the max GIF dimensions for Twitter/X? Twitter accepts GIFs up to 15MB and 1280x1080 pixels. Practically, staying under 5MB and under 720px wide produces the best feed results after their compression.