Video to GIF
Converter

GIF wins on universal autoplay. It plays inline in every email client, every chat platform, every CMS, and every browser back to Netscape. No <video> tag, no autoplay muted playsinline dance, no codec licensing. For a 2-second product demo inside a GitHub README, a Stripe Slack notification, or a marketing email, GIF is still the lowest-friction format in 2024.

Where GIF fits: GitHub READMEs (no video player), Slack and Discord chat (inline preview), Notion/Confluence docs (lightweight embed), email newsletters (most clients still block <video>), Twitter/X DMs, support ticket attachments. Anywhere the consumer might be a mail client or aggressive corporate sandbox.

Where MP4/WebM wins by a wide margin: any web page where you control the markup (use <video autoplay muted loop playsinline>), Twitter/X tweets (they auto-convert uploaded GIFs to MP4 anyway), Instagram and TikTok (video-native platforms), product landing pages, blog posts on your own domain. MP4 H.264 at the same visual quality is typically 10–50× smaller than the equivalent GIF.

WebP animation is the modern compromise: GIF-like autoplay semantics, MP4-like compression, supported in every browser since 2021 and in iOS Mail and Slack. If your target platform supports WebP (most do now), prefer it — but GIF is still the only safe bet for unknown-environment delivery like email and legacy systems.

GIF's compression is indexed-color RLE with LZW. Each pixel is one of 256 palette entries, and runs of identical pixels compress well. This means file size scales roughly with frames × pixels × palette diversity. Halving any one of those approximately halves the size. The art is picking which to cut without ruining the result.

Frame rate: video sources are usually 24, 30, or 60 fps. GIFs rarely need more than 12-15 fps — the human eye barely sees the difference for short loops, but file size drops proportionally. For UI demos with cursor motion, 10 fps is often enough. For sports or fast action, push to 15 fps; above 20 fps the size penalty rarely justifies the smoothness gain.

Width is the highest-leverage knob. A 1080p GIF is roughly 9× the size of a 360p GIF at identical frame count and palette. For GitHub READMEs use 600-800px. For Slack/Discord reactions use 300-480px. For email signatures use 200-320px. Always downscale at the source rather than letting the platform downscale on display.

Palette generation matters more than people realize. Desktop FFmpeg can build a custom 256-color palette per clip in two passes (palettegen + paletteuse), which beats a naive single-pass conversion on gradients. ConverterUp uses FFmpeg's standard GIF encoder with Lanczos scaling, which works well for UI demos, screen recordings and reactions; for gradient-heavy footage, keep the width modest and expect some banding.

Color banding in gradients is GIF's signature failure mode. A smooth sunset or skin-tone gradient turns into visible 5–10 px color bands because 256 palette colors cannot represent millions of shades. The fix is to reduce the gradient's prominence — crop or reframe so the gradient is a small portion of the frame, lower the width, or accept the banding as part of the GIF aesthetic.

Files larger than expected are almost always caused by: dimensions too high (the #1 cause), frame rate above 15 fps, complex backgrounds with film grain (every frame has a different pseudo-random pattern, which destroys RLE compression), or a long duration. If your 4-second clip is >5 MB, drop the width by 30 % first, then the frame rate.

Audio is permanently lost because GIF has no audio container. ConverterUp drops the audio track silently. If your demo relies on audio (e.g., a sound effect at a specific moment), export to MP4 or WebM instead. There is no workaround — GIF89a simply has no audio spec.

Looping vs single play: GIF supports infinite loop, fixed N-loop, or single play via the Netscape Application Extension block. ConverterUp exports GIFs that loop forever, because almost every use case wants it (reactions, demos, microinteractions).