A 1987 format with no interframe compression
GIF arrived on CompuServe in 1987, eight years before anyone was streaming video over a modem. It stores animation the only way it knows how: as a stack of still images, each one compressed on its own with LZW, a general-purpose scheme that predates every idea modern video codecs are built on.
The idea GIF is missing is the important one. H.264 spends most of its effort describing how one frame differs from the last, so a static shot with a talking head in the middle costs almost nothing per frame. GIF has a limited version of this at best and no motion estimation whatsoever, so a panning camera is close to the worst case: every pixel changes, and every frame pays full price.
It survives anyway because of where it plays. Slack, Discord, GitHub comments, most forums and most email clients treat a GIF as an image and animate it inline with no play button and no codec negotiation. An MP4 in the same place is an attachment somebody has to decide to open. That is the whole trade, and it is why a format this inefficient is still in daily use.
Palettegen and paletteuse in one filter graph
The second constraint is colour. A single GIF frame can reference at most 256 colours, and a naive converter handles that by quantising against a fixed generic palette, which is where the muddy skin tones and speckled gradients in bad GIFs come from.
This tool runs FFmpeg’s two-stage palette technique instead. The filter graph reduces the frame rate and scales the video first, then splits that stream in two: one branch feeds palettegen, which studies the actual colours in your footage and builds a 256-entry palette tailored to them, and the other branch is held back and mapped through that palette by paletteuse. Both branches live in one -filter_complex invocation, so your clip is decoded once rather than twice.
Building the palette after the scaling matters more than it sounds. Downscaling blends neighbouring pixels into new intermediate colours, so a palette computed from the original frames would be measuring colours that no longer exist by the time they are needed.
One palette covers the whole animation. That is the right call for a single continuous shot, and it is the weak spot for a clip that cuts between very different scenes, which has to share those 256 entries across all of them.
Frame rate and width are the only two levers
Everything else about this conversion is fixed, which is deliberate: Frame rate and Width are the two settings that actually move the file size, and burying them among encoder options would not help anyone.
Frame rate multiplies directly. Twenty frames a second is twice the stored images of ten, and because there is no meaningful interframe compression, roughly twice the bytes. 15 fps (recommended) reads as smooth for most footage; 10 fps (smaller file) is visibly steppier on fast motion but perfectly fine for a screen recording of a cursor and some menus.
Width behaves worse than linearly, since halving the width roughly quarters the pixel count per frame. 480 px (recommended) is legible in a chat window and reasonable to send. Original size emits no scale filter at all, so each frame keeps whatever dimensions the source had, and it is the setting most likely to produce a file too heavy to post anywhere. The three pixel widths are the ones written as min(iw,W), which is why none of them ever enlarges a source that is already narrower than the width you picked.
Turning the clip into a GIF
- Drop your MP4 into the box above, or click Choose a file. Short clips are what this format is for.
- Choose a Frame rate. Leave it at 15 fps (recommended) unless the motion is slow, in which case 10 fps (smaller file) stores a third fewer frames.
- Choose a Width. 480 px (recommended) suits chat and forum posts; 320 px (chat size) is the safe pick when a size limit is involved.
- Click Convert MP4 to GIF, then download the result, which keeps your filename with a
.gifextension.
When the GIF comes out larger than the MP4
This surprises people constantly, and it is not a fault. Your MP4 was compressed by a codec designed around the fact that consecutive frames look alike; the GIF is not. A ten-second 1080p clip that fits in a couple of megabytes as H.264 can become something far heavier as a full-size GIF, and the size line the tool shows after a run will say so plainly.
Three things bring it down, in order of effect. Shorten the clip, because length is the multiplier everything else sits on top of. Then drop the width, which attacks pixels per frame. Then drop the frame rate. If you have already made the GIF and only want it lighter, Compress GIF works on the finished file, and Trim Video cuts the source first so the conversion never produces the excess in the first place.
The audio is dropped and the clip is never trimmed
Two limits are worth stating outright. The command passes -an, so any soundtrack is discarded rather than silenced, because the container has nowhere to put it. And there is no start or end time on this page: whatever length you drop in is the length that gets converted.
There is no imposed file size limit either, since your own device does the work, but a long source at 20 fps and original width will happily eat your memory. The practical ceiling is the tab, not a rule.
Where Compress GIF and GIF to MP4 fit in
Going the other way is often the better answer. GIF to MP4 takes an existing animation and re-encodes it as video, which is what you want for a page you control, where a small looping MP4 beats a heavy GIF on every measure except pasteability. Images to GIF builds an animation from a folder of stills instead of a video, and the rest of the collection sits under video tools alongside the video converter and compression guide.