Two ways to store motion
A GIF is a stack of pictures. Frame one is a complete image. Each frame after that, in MDN's description, holds the parts of the image that changed. Sounds efficient. In practice, on real footage where the camera moves or the light shifts, nearly everything changes, so nearly every frame is close to a full picture again.
A video codec does something a GIF cannot. It predicts. Given the previous frame and a description of how blocks of pixels moved, it reconstructs the next one and stores only the residual error. On footage where things move rather than teleport, that residual is tiny.
Ten seconds of 30 frames per second is 300 frames. A GIF stores something close to 300 pictures. An MP4 stores a handful of full frames and 290-odd sets of small corrections. The size gap that produces is not a matter of settings. The difference is structural, and it usually runs somewhere between five and twenty times.
Why the colours look wrong too
Every pixel in a GIF is an 8-bit index into a palette, and MDN puts the ceiling plainly: a palette has at most 256 entries. Two hundred and fifty-six colours for the whole frame.
A photograph, or a frame of video, routinely contains tens of thousands. Squeezing that into 256 is what gives GIFs their characteristic banding across skies and skin, and the speckled dithering that tries to fake the missing shades by scattering the ones it has.
Nothing in the compression is responsible for that. LZW, the algorithm GIF uses, is lossless. The damage happens before compression, at the moment the image is reduced to a palette, and no amount of quality slider undoes it afterwards.
For flat graphics, screen recordings of a terminal, or a logo bouncing around, 256 colours is plenty and the banding never appears. For anything with a gradient or a face in it, it always does.
The knobs that actually matter
If you need a GIF anyway, and there are reasons you might, four decisions set the size.
Frame rate. Halving 30fps to 15fps halves the file, and for most short clips the motion still reads. Ten is often fine for a reaction clip. Anything under eight starts to look like a slideshow.
Dimensions. Pixels are the unit of cost. A 640 pixel wide GIF has four times the pixels of a 320 wide one, and roughly four times the bytes. Most GIFs are viewed at a third of the size they were exported at.
Duration. Obvious and underused. Three seconds looped reads better than eight seconds once, and is less than half the size.
Palette. Dropping from 256 to 128 or 64 colours reduces bytes per pixel and often looks no worse on the content that suits GIF in the first place. On photographic content it looks worse quickly, which is your cue that this should not have been a GIF.
The video to GIF tool exposes those four directly, and shows the output size before you commit, which is the only honest way to make the trade. If the result is still too heavy, running the frames through an image resizer first is usually the biggest single win.
The platforms have already decided
Upload a GIF to X, and it is converted to a video on arrival. Several other large platforms do the same, or serve an MP4 behind a GIF-shaped player. The GIF you made is, in many places, never actually delivered as a GIF.
They do it for the reasons above. Bandwidth costs money, and a 20MB file that could be 2MB is a bill.
That tells you what the format is good for now. GIF survives because it autoplays without any player controls, loops by default, and drops into anything that accepts an image, including places that will not accept a video file at all: messaging apps, older forums, email signatures, documentation. Where those constraints apply, GIF is still the right call. Where they do not, it rarely is.
Memes are an interesting middle case. A static image with text on it is not an animation problem, and a meme generator should be exporting a PNG or JPEG, not a GIF. People reach for GIF out of habit, and pay for it in file size and in colour banding across the photo underneath the caption.
What to use instead, honestly
For animation on a web page you control: an MP4 or WebM video element with autoplay, muted, loop and playsinline attributes. It behaves like a GIF to the viewer and costs a fraction of the bytes. Browsers require the muted attribute for autoplay, which is fine because a GIF had no sound anyway.
For animation that must be an image file: MDN's own guidance is to consider WebP, AVIF or APNG for animation sequences. Animated WebP in particular supports full colour and real compression, and is widely supported now. The catch is the long tail of places that still expect a literal .gif, which brings you back to the previous section.
For a still image that somebody exported as a GIF because the tool defaulted to it: convert it. A photo as PNG or JPEG through the image compressor will be smaller and will have its colours back.
The question to ask before exporting is not "how do I make this GIF smaller" but "does this need to be a GIF". Most of the time the answer is no, and that answer removes the problem rather than shrinking it.
Questions people ask
Because a GIF stores frames as pictures and a video codec stores the differences between frames. On real footage, where almost every pixel changes a little each frame, the GIF ends up holding something close to a full image per frame, while the video holds a few full frames plus small corrections. The gap is usually five to twenty times.
A GIF frame can hold at most 256 colours, chosen from a palette. Photographs and video frames contain far more, so the conversion collapses smooth gradients into bands and scatters dots to simulate the missing shades. The compression itself is lossless; the loss happens at the palette step and cannot be undone afterwards.
Reduce frame rate to 10 to 15fps, shrink the pixel dimensions, cut the duration, and lower the palette to 128 or 64 colours. Dimensions are the biggest lever, since a GIF half as wide has a quarter of the pixels. If it still looks bad at that point, the content probably should have been a video.
Yes. GIFs uploaded there are converted to video on arrival, and several other platforms do the same or serve an MP4 behind a GIF-style player. The GIF you export is often never delivered as a GIF, which is a strong hint about which format the platforms consider practical.
On a page you control, a muted looping MP4 or WebM video, which behaves like a GIF and is far smaller. Where it must be an image file, MDN recommends WebP, AVIF or APNG for animation. GIF remains the right choice only where the destination will not accept anything else, such as many messaging apps and email.
