The GIF is one of the oldest image formats still in everyday use online, and its quirks — the color banding, the choppy motion, the surprisingly large file sizes — all trace back to decisions made in a format designed decades before anyone was making animated reaction images out of it.
GIFs Are Just a Sequence of Frames
An animated GIF isn't really "video" in any technical sense — it's a container holding a sequence of separate still images (frames), each with its own timing value, played back in order and looped according to a repeat setting. There's no motion compression or interpolation between frames the way a video codec does it; each frame is a complete, independent image that just happens to be shown right after the last one.
The 256-Color Limit
Every GIF frame is stored using an indexed color palette capped at 256 colors total — a hard limit written into the original 1987 GIF89a specification, long before anyone was routinely working with millions of colors on screen. When a source photo has more distinct colors than that, the encoder has to approximate: nearby colors get mapped to the closest available palette entry, or dithered (mixed in a pattern) to simulate a color that isn't actually available. This is exactly why a GIF of a photo with a smooth sky gradient often shows visible banding, while a GIF of a simple screenshot or flat-color graphic looks nearly identical to the source — it never needed more than 256 colors to begin with.
Frame Delay vs. Frame Rate
GIFs don't use a frame rate the way video does — instead, each individual frame carries its own delay value specifying how long it should stay on screen before advancing. That timing field in the GIF spec was originally defined in centiseconds (hundredths of a second), a detail left over from the format's original design. Most modern GIF-making tools let you set delay in the more familiar milliseconds and convert it internally, which is also why some GIF delay values you'll see in the wild look oddly rounded — they're really multiples of 10ms under the hood.
How Mismatched Photo Sizes Get Reconciled
Every frame in a GIF has to share the same canvas dimensions, so when source photos come in different sizes, something has to give. A common approach is to lock the output size to the first image and then center-crop every other image to fill that same frame without stretching or distorting it — the same behavior as CSS's object-fit: cover. The tradeoff is that anything outside the target frame gets cropped away rather than squeezed to fit, so photos with very different aspect ratios from the first one can lose parts of the edges.
Why GIFs Get Big Fast
Encoding a GIF — converting each frame to its indexed palette and assembling the frame timing data — is genuinely processor-intensive work. It's also inherently less efficient than modern video compression: video codecs typically only store what changed between frames, while GIF frames are largely independent, so file size scales fairly directly with the number of frames, their dimensions, and how much color detail each one contains. More frames or a higher quality setting both push the file size and encoding time up together.
Try It Instantly
Turn a set of photos into an animated GIF with our free GIF Maker — reorder frames, set the delay and loop, and everything runs right in your browser with nothing uploaded.
FAQ
Why can GIFs only display 256 colors at once? The GIF format stores each frame using an indexed color palette capped at 256 colors, a limitation baked into the original 1987 GIF89a specification. This is why photos with smooth gradients or lots of color often show visible banding or dithering in a GIF, while flat-color graphics and screenshots tend to look nearly identical to the source.
Why is GIF frame delay usually described in hundredths of a second? The GIF format's timing field was originally defined in centiseconds (hundredths of a second) rather than milliseconds, a holdover from the original specification. Most modern GIF tools, including this one, let you set the delay in the more intuitive milliseconds and convert it internally, but that's the reason you'll sometimes see GIF delay values that look oddly rounded.
How does a GIF maker handle photos that aren't all the same size? The output canvas is set to match the dimensions of the first image, and every other frame is center-cropped to fill that same size without stretching or distorting it — the same behavior as CSS's object-fit: cover. Anything outside the frame's edges is simply cropped away rather than squeezed to fit.
Why do GIFs take a while to generate and produce such large files compared to a video? GIF encoding — converting each frame to an indexed palette and assembling the timing data — is genuinely processor-intensive, and unlike a video codec, GIF doesn't compress between frames based on what changed, so file size scales fairly directly with frame count, dimensions, and color complexity.