There is a specific disappointment every internet user has felt at least once: you take a nice short video clip, convert it to a GIF for a chat or a blog post, and the result looks like it was recorded in 2004 through a fish tank. Colors banded, edges chunky, file 12 MB for two seconds of footage. This post is about why that happens and what to change to make it stop.
Why GIFs look worse than the video they came from
GIF was invented in 1987. It has two hard limitations that no modern video format has. First, it can only use 256 distinct colors per frame — a palette. Second, it has no real compression across frames: each frame is basically its own image. A 30-second HD video is thousands of frames, each capped at 256 colors, with nothing shared between them. The math just doesn't work.
Modern video formats (MP4/H.264, WebM/VP9, AV1) use full-color frames plus interframe compression: they store the difference between one frame and the next, which is usually tiny. That's why a 30-second MP4 can be 2 MB and the equivalent GIF is 20 MB. GIF is asking you to store the same information the world's worst possible way.
The three settings that actually matter
If you must have a GIF (chat platforms that auto-loop them, README files, ancient CMSes), three settings decide how it looks and how heavy it is.
1. Framerate. GIFs feel smooth at 15 fps, acceptable at 12, choppy below 10. Almost nobody needs 30 fps in a GIF — halving the framerate roughly halves the size for almost no perceived quality loss. Start at 15 fps and drop from there.
2. Palette. This is the invisible one. A good GIF encoder builds a custom 256-color palette from the actual pixels in your video — flesh tones for a face-cam, greens for a landscape. A cheap encoder uses a fixed palette and everything looks banded. Bluebird's Video-to-GIF tool builds an optimized palette per clip; most "convert to GIF" websites do not.
3. Dimensions. A 1080p GIF is a bad idea. Anything above ~640 pixels wide is almost always wasted — it will be displayed at 400 pixels wide in chat or a blog anyway, and the extra pixels just quadruple the file. Halve the dimensions before you convert; you can barely tell the difference visually and the file drops by 4×.
The one-line rule for size
A rough formula that holds up in practice: 480 px wide × 15 fps × 5 seconds ≈ around 2–3 MB for typical footage. If you're getting much bigger than that, one of your three settings is too high. If you need it much smaller, drop the framerate first, then the width. Cutting length is the last resort — 3 seconds of good-looking GIF beats 8 seconds of mud.
When you shouldn't use a GIF at all
Twitter/X, Bluesky, Slack, Discord, most modern CMSes, and every major blogging platform now auto-play muted MP4/WebM as if they were GIFs. When you upload a GIF, most of them silently convert it to MP4 in the background anyway. For most cases, the right move is: upload the MP4 directly. It will be sharper, smaller, and won't be re-encoded twice.
The exceptions worth keeping in your pocket: emails (many mail clients will not play video but will animate a GIF), README files on GitHub (limited to a size cap, but GIFs work reliably), and older chat apps or intranet wikis that don't support inline video. In those cases, follow the settings above and you'll get something respectable.
One trick most people miss: trim before you convert
The single biggest quality-per-byte win for a GIF is cutting the source clip to the exact seconds you actually need before conversion, not after. Every extra second is another 15 frames × 256 colors × your dimensions. Use a video trimmer to cut to the tightest possible in/out points, then convert.
A tightly cut 3-second GIF at 480×270, 15 fps, with a per-clip palette will look genuinely good, come in under 2 MB, and load instantly. That's the target.
