What Technically Changes When a GIF Becomes a Video?

When you convert a GIF to MP4 the file shrinks tenfold but the picture stays nearly identical. How is that possible, and what actually changes during the conversion? This article explains the structural differences between the two formats and what happens at each step of the conversion.

Two different animation models

In GIF, animation is a sequence of independent frames. Each frame:

• Can have its own color palette (up to 256 entries)
• Has its own delay (in hundredths of a second)
• Can have its own position and size (a partial rectangle rather than a full frame)
• Has its own disposal method (what happens before the next frame)

In video, animation is frames laid out on a fixed time grid. The frame rate is usually constant (25, 30, 60 fps) and each frame is displayed for the same duration.

This basic difference in model creates the first challenge of conversion.

Timing: from variable delays to a constant frame rate

A GIF's frame delays might look like this:

Frame 1: 10 (0.10 s)
Frame 2: 10 (0.10 s)
Frame 3: 25 (0.25 s)  ← pause
Frame 4: 10 (0.10 s)
Frame 5:  5 (0.05 s)  ← quick transition

Video expects a constant frame rate. The converter's options:

1. Pick a high enough frame rate and repeat frames. In the example above, if 20 fps is chosen (0.05 s per frame), the 0.25-second frame is repeated five times. Timing is preserved exactly and the frame count goes up — but that doesn't create a size problem, because video codecs compress repeated frames very efficiently.

2. Pick an average frame rate and approximate. Simpler, but timing differences appear.

Most converters use the first route. Even so, if your GIF's delays are very irregular a slight difference in rhythm may be perceptible.

One detail: some very old GIFs carry a delay value of 0 (as fast as possible). Browsers usually raise that to some minimum, and different browsers use different minimums. When you convert such a GIF to video, the speed can differ from what you saw in the browser.

Compositing partial frames

In a GIF, a frame can be a small rectangle that draws only the changed region on top of the previous frame. In an animation with a static background this saves a lot of space.

Video has no such concept; every frame is full size.

The converter has to composite the GIF frames in sequence to produce a complete image for each frame. To do that it needs to interpret the disposal method correctly:

| Method | Meaning | |---|---| | Unspecified | Leave the frame as it is | | Do not dispose | Keep the frame, draw the next one over it | | Restore to background | Clear the frame's region with the background color | | Restore to previous | Return the frame's region to its previous state |

Misinterpreting this shows up in the conversion as "ghost" trails or accumulated residue. That's a rare problem with well-written converters, but it can appear with very old or non-standard GIFs.

Color: from palette to full color (but no going back)

In a GIF each pixel is a palette index. During conversion those indices are resolved into actual RGB values.

The video format supports full color (16.7 million), so there's no technical limit.

But the source has already been reduced to 256 colors. The lost color information doesn't come back. The video stores those 256 colors using full-color capacity, and the result looks visually identical to the GIF.

An interesting side effect: if dithering was applied to the GIF (the dotted pattern used to hide the color limit), that pattern carries into the video. For the video codec that noise is difficult — the codec mistakes it for real detail and spends bits on it. Without a sufficient bitrate, the dither pattern blurs or leads to block artifacts.

Transparency: the feature that disappears

GIF supports binary transparency: a pixel is either fully transparent or fully opaque. There's no in-between, which is why transparent GIFs have jagged edges.

Common video codecs (H.264 and VP9 standard profiles) don't carry an alpha channel. Every pixel is assumed opaque.

During conversion transparent pixels have to be filled with some color — usually black or white. The result is that regions showing through in the GIF become flat color in the video.

If you need transparency, video isn't the right target. The alternatives:

• Animated WEBP: 8-bit alpha, good compression.
• APNG: 8-bit alpha, larger file but broad support.

Both are better than GIF's binary transparency — with 256 transparency levels they give smooth edges.

Chroma subsampling

This is one of the most technical but most visible effects of conversion.

The human eye is far more sensitive to changes in brightness (luma) than to changes in color (chroma). Video codecs exploit this: they store brightness information at full resolution and color information at half resolution.

This scheme is called 4:2:0 and it's the default for common video encoding. Color information is halved both horizontally and vertically — so a quarter of the color data is stored.

On photographic content this is nearly invisible. But on the kind of content GIFs often carry it's noticeable:

• Sharp colored edges: red text on a white background gets slight blurring at the edges.
• Thin lines: colored interface elements soften.
• Small text: legibility can drop.

Some codecs support the 4:4:4 profile (color information stored at full resolution). On screen recordings and animations containing text this makes an obvious difference, but the file grows and compatibility narrows.

The even-number constraint

Because 4:2:0 subsampling stores color information in 2×2 pixel blocks, it requires width and height to be even numbers.

GIFs have no such constraint; dimensions like 401×267 are common.

The converter solves this in one of two ways:

• Cropping: a single column/row of pixels is dropped (401 → 400).
• Padding: a single pixel is added (401 → 402), usually black.

Neither is visually noticeable, but the dimension change shows up in the metadata.

Compression efficiency: the real gain

Now to the reason behind the dramatic difference in file size.

GIF's tools:

• LZW lossless compression (finds repeating patterns)
• Partial frames (the changed rectangular region)
• Transparent pixels (skipping unchanged pixels)

A video codec's tools:

• Motion estimation (finds where a block moved to)
• Intra prediction (predicting from neighboring pixels)
• Bidirectional prediction (looking at previous and next frames)
• Frequency transform and quantization (discarding visually insignificant detail)
• Variable block sizes
• Entropy coding

The difference is categorical. GIF says "this region changed, here are the new pixels"; a video codec says "that block from the previous frame moved 12 pixels right and got slightly darker."

On top of that comes lossy operation: a video codec can discard detail that won't be noticed visually. GIF's LZW is lossless and has no such flexibility.

The result: typically a 5-10x difference in size for the same content.

What's lost, what's gained

| Aspect | GIF | After video | |---|---|---| | File size | Large | 5-10x smaller | | Color range | 256 (limit) | Full color (but source is 256) | | Transparency | Binary | None | | Email support | Yes | No | | Autoplay | Native | Requires an attribute | | Sharp colored edges | Intact | Slight softening (4:2:0) | | Timing flexibility | Per frame | Constant frame rate |

In summary

GIF and video handle animation with different models: in GIF each frame has its own delay, palette and partial region; in video there are full frames on a fixed time grid. Conversion composites the frames and normalizes the timing to a constant frame rate. In terms of color there's no loss, but no gain either — the 256-color limit has already been applied. Transparency, though, is lost, because common video codecs carry no alpha channel. Chroma subsampling creates slight softening on sharp colored edges, and the even-number constraint may require a single-pixel crop. In exchange the gain is large: video codecs' motion estimation and lossy operation store the same content at typically a fifth to a tenth of the size.