GIF to MP4, Explained

After reading this you will understand why an MP4 of the same animation can be one tenth the size of the GIF, how H.264 achieves that, and how to convert without losing quality you care about.

What the conversion actually does

An animated GIF stores a sequence of full frames. Each frame is a palette image, and the palette can hold at most 256 colors. There is no motion compression worth the name: GIF's LZW coding squeezes runs of identical pixels within a frame, but it does not describe one frame in terms of the previous one. A 3 second clip of a person waving stores every pixel of every frame more or less independently.

An MP4 file carries an H.264 video stream. H.264 keeps a few full frames as reference points and describes the frames between them as small differences: "this 16 by 16 block moved 4 pixels left, and here is the tiny correction." When most of the picture holds still, those differences are nearly zero and cost almost nothing to store.

Take a 480 by 270 clip that runs 4 seconds at 15 frames per second. As a GIF it might weigh 6.2 MB. Re-encoded to H.264 at a reasonable quality it lands around 380 KB. That is a factor of about 16. The picture looks the same or better, because H.264 is not stuck with 256 colors.

When to convert and when not

Convert when the GIF is large and you control where it plays. Modern browsers, phones, and messaging apps all decode H.264. An MP4 that autoplays muted and loops behaves like a GIF to the viewer while transferring a fraction of the bytes.

Keep the GIF when you need it to work in contexts that only accept image files: an email signature, an old chat client, a sticker slot that rejects video, or a documentation system that inlines images but not <video> tags. GIF is a worse video format but a more portable one.

If your source is already a video and you only made a GIF for sharing, skip the round trip. Going video to GIF to MP4 throws away color and detail at the GIF step that H.264 can never recover. Convert from the original video instead.

Where the size savings come from

You can estimate a GIF's uncompressed cost and see why compression matters. A GIF frame stores one palette index per pixel, and an index is 8 bits (1 byte) because the palette holds up to 256 entries.

S_{\text{raw}} = w \times h \times f \times t \times 1 \text{ byte}

Here w and h are width and height in pixels, f is the frame rate in frames per second, and t is the duration in seconds. For the 480 by 270, 15 fps, 4 second clip that is 480 \times 270 \times 15 \times 4 = 7{,}776{,}000 bytes, about 7.4 MB before any compression. LZW inside the GIF brings that down to roughly 6 MB for typical content, so GIF compression saves maybe 20 percent.

H.264 works on a different axis. Instead of coding each frame alone, it predicts motion. A rough model for the encoded size is the number of frames times an average cost per frame, where still frames cost far less than the first frame:

S_{\text{h264}} \approx S_I + (N - 1) \times \bar{S}_P

S_I is the size of the first full frame (the I-frame), N is the total frame count, and \bar{S}_P is the average size of a predicted frame. In our clip N = 60. If the I-frame is 45 KB and each predicted frame averages 5.5 KB, the total is about 45 + 59 \times 5.5 \approx 370 KB. The exact numbers depend on how much the picture moves.

Quality, bitrate, and the CRF knob

H.264 encoders usually target quality with a constant rate factor, or CRF. Lower CRF means higher quality and larger files. The scale runs from 0 (lossless) to 51 (worst). The default of 23 is visually clean for most content. Each step of about 6 roughly halves or doubles the bitrate.

\text{bitrate}(q) \approx b_0 \times 2^{-(q - q_0)/6}

q is the CRF you choose, q_0 is a reference CRF, and b_0 is the measured bitrate at that reference. If a clip encodes to 800 kbps at CRF 23, then CRF 29 gives about 800 \times 2^{-1} = 400 kbps, and CRF 17 gives about 800 \times 2^{1} = 1600 kbps. Halving the size costs roughly one CRF step of six.

Bitrate falls by about half for every six steps of CRF. The marker sits at the default CRF 23.

A worked conversion using the demo defaults

From a 6 MB GIF to a 370 KB MP4

Load the demo clip: 480 by 270 pixels, 60 frames, 15 fps, running 4 seconds. Run the conversion with the default settings and follow the arithmetic.

Raw palette size: 480 \times 270 \times 60 = 7{,}776{,}000 bytes, so 7.4 MB before compression.
The GIF on disk is 6.0 MB, meaning LZW recovered about 19 percent.
H.264 at CRF 23 targets roughly 800 kbps for this motion level. Over 4 seconds that is 800 \times 4 / 8 = 400 KB of video payload.
Subtract a little because the last group of frames codes cheaply, and add MP4 container overhead of a few KB. The output lands near 370 KB.
Ratio: 6000 / 370 \approx 16.2. The MP4 is about 16 times smaller.

The width 480 and height 270 are both even, so no padding is added. If the GIF were 481 pixels wide, one column of padding would make it 482, because H.264 requires even dimensions.

Reading the result

Check three numbers after conversion. First, the ratio of GIF size to MP4 size. A ratio of 5 to 20 is normal. A ratio near 1, or an MP4 larger than the GIF, means the source had heavy motion or noise on every frame, so prediction had little to reuse.

Second, the frame rate. GIF frame timing is stored per frame in hundredths of a second, so a GIF can have an odd effective rate like 12.5 fps. The MP4 uses a fixed rate. If motion looks slightly stuttered, the source timing did not map cleanly onto the chosen rate.

Third, the visible quality of flat color areas. Cartoons and screen recordings with large solid regions compress beautifully. Film grain, dithering, and gradients cost more bits and may show blocking at high CRF.

The GIF dwarfs both MP4 outputs. Dropping from CRF 23 to CRF 29 roughly halves the MP4 again.

Common mistakes

The most common one is expecting an MP4 to autoplay in a browser the way a GIF does. A <video> tag needs the autoplay, muted, and loop attributes, and browsers block autoplay unless the video is muted. A converted GIF has no audio, so muting is free.

Do not push CRF very low to "keep quality." A GIF only ever had 256 colors and possibly dithering. Encoding at CRF 14 will faithfully preserve the dithering noise and inflate the file. CRF 23 to 28 usually looks identical and stays small.

Another trap is upscaling. Enlarging a 240 pixel wide GIF to 720 pixels before encoding adds bits without adding detail. Keep the output at the source resolution unless a target device demands otherwise.

Related tools on this site

To go the other direction, from a video clip to a shareable animation, use Video to GIF. If you need only the soundtrack of a video, Extract Audio from Video pulls it to MP3, WAV, or FLAC. For converting standalone sound files between formats, see the Audio Format Converter.

Frequently asked questions

Why is my MP4 not much smaller than the GIF?

The GIF probably changes across the whole frame every step: heavy grain, a full-screen dither pattern, or fast camera motion. H.264 saves space by predicting still regions, so a clip with no still regions gives a ratio near 2 or 3 instead of 15.

Does converting add or remove audio?

Neither. GIF has no audio track, so the MP4 comes out silent. That is why muted autoplay works without a user gesture.

Can I get a perfect, lossless copy of the GIF as MP4?

You can set CRF to 0 for lossless H.264, but the file will often be larger than the GIF and offers no benefit, since the GIF already discarded color to 256 entries. CRF 20 to 23 reproduces every color the GIF actually contains.

Why did the output dimensions change by one pixel?

H.264 requires even width and height. If your GIF has an odd dimension, one row or column is padded so the encoder accepts it. A 301 by 200 GIF becomes 302 by 200.

Is my file uploaded anywhere?

No. The encoder runs as WebAssembly inside your browser. The file stays on your machine.

Try it yourself in the tool