MP4 to GIF.

Change three things, in this order: shorten the range, drop the width, and cut the colours. Length and pixel count are multipliers on every frame, so two seconds at 320 px is a quarter the size of four seconds at 480 px before anything else is touched. Then take the palette down from 256 to 64 or 32, which on dithered footage is usually a bigger saving than it costs in looks. Frame rate is the last lever, because dropping below 12 starts to look like a slideshow. The readout here updates on every one of those, so you can find the combination that fits instead of exporting four times to guess.

Because GIF compresses each frame by finding runs of the same palette index, and nothing else. It has no motion compensation, so a GIF cannot say this frame is nearly the last one; every frame pays close to full price. Flat graphics compress enormously and camera footage barely compresses at all, so grain, a handheld wobble, and a busy background all multiply the size while the duration and resolution stay the same. Dithering makes it worse, on purpose, because it replaces flat areas with texture. Two clips of the same length and size can differ tenfold, which is exactly why this tool measures rather than predicts.

Ordered, unless you have a reason. It lays a fixed 4x4 crosshatch over the picture, which is stable from frame to frame, so it does not crawl or shimmer while the animation loops, and it compresses better than error diffusion. Choose diffusion (Floyd-Steinberg) for a single-subject clip with smooth gradients, like a sunset or a face against a plain wall, where the grain looks better than the crosshatch and the crawling does not show. Choose none only for flat graphics, screen recordings of text, or cartoons, where there is nothing to dither and the bands are actually the right answer: it is also the smallest file of the three by a wide margin.

Because the format was finalised in 1989 and stores one byte per pixel pointing into a colour table of at most 256 entries. There is no 24-bit GIF. That is why quantising matters: your clip has thousands of colours and something has to choose which 256 survive. A global palette picks one set for the whole animation, which keeps the file smaller and stops colours shifting between frames; a per-frame palette gives each frame its own 256, which looks better on a clip that changes scene and costs real bytes. Dropping to 64 or 32 colours is the single most effective way to shrink a GIF, and on footage with dithering on it often costs less than it sounds like it should.

Reddit takes GIFs up to 100 MB, which is by far the most generous. Twitter caps GIF uploads at 15 MB. Discord stops at 10 MB on the free tier, 50 MB with Nitro Basic and 500 MB with Nitro. GitHub allows 10 MB for images and GIFs in issues and pull requests. Slack allows up to 1 GB per file, so it is effectively never the constraint. The tags under the size readout check your number against the four that actually bite, and they update as you change settings.

Most of the time, honestly, if the destination supports it. An MP4 with H.264 inside is five to twenty times smaller than the same clip as a GIF, carries real colour instead of 256 entries, and every social platform autoplays and loops it. Use a GIF when the destination will not take video: a GitHub issue or pull request comment, a README, an email, some wikis and documentation systems, or a chat where you want the thing to move without a click. That is a real and common set of places, which is why this tool exists, but if you are posting to Twitter or Discord and just want a short loop, upload the MP4 and let the platform loop it.

Not a hard one in seconds, but there is one in frames: 1200, which is 100 seconds at 12 frames per second or 50 at 24. Past that the encode takes long enough to feel broken and the file is too big for anywhere. In practice a GIF stops being a good idea somewhere around ten seconds, and the size readout will tell you that faster than any rule could.