30 FPS Does Not Exist in GIF

Ask any GIF encoder for 30 frames per second and it will say yes. It is lying, and the reason is four bytes deep in the file format: a GIF frame’s delay is a whole number of hundredths of a second, and 100/30 is not a whole number.

Every frame in a GIF carries its own delay, stored in a Graphic Control Extension block that looks like this:

0x21 0xF9 0x04 <packed> <delay lo> <delay hi> <transparent> 0x00

The two delay bytes are a 16-bit little-endian integer, and its unit is hundredths of a second. Not milliseconds. Not a rational number. A whole count of centiseconds, from 0 to 65,535.

That single fact fixes the entire set of frame rates a GIF can express. If the delay must be an integer n, the rate must be 100/n:

100, 50, 33.33, 25, 20, 16.67, 14.29, 12.5, 11.11, 10, 9.09, 8.33, 7.69, 7.14, 6.67, 6.25, 5.88, 5.56, 5.26, 5.00 …

Thirty is not in that list. Neither is 60, nor 24, nor 15 — three of the four rates most video is shot at.

What an encoder actually does with your 30

It computes 100/30 = 3.33 centiseconds, discovers it cannot store that, and rounds to 3. Your GIF now runs at 33.33 fps, 11.11 % fast. The error is not the interesting part; the duration is:

Ten seconds of video captured at 30 fps is 300 frames. At 3 centiseconds each that is 900 centiseconds — nine seconds. The GIF ends a full second before the clip it was made from. Ask for 60 and it runs long instead: 600 frames at 2 cs is 12.00 seconds.

Of the rates anyone actually asks for, only 50, 25, 20, 10 and 5 come back exactly. Everything else drifts, and it drifts by a fixed percentage that grows with the length of the clip. Cut a GIF against music and this is the whole explanation for why the loop walks away from the beat.

Encoders hide it by alternating two delays

Here is where it stops being arithmetic and starts being a thing you can read out of a file on your disk. A well-made encoder does not round every frame the same way — it dithers, so the average comes out right.

We took a GIF produced by ffmpeg, nominally at 12 fps, and walked its blocks to read the delay of every frame:

8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8

Twenty-four frames. 200 centiseconds. Exactly 2.00 seconds, which is exactly 12.0000 frames per second on average. The average is perfect — and no frame in the file is 12 fps. Consecutive frames are 80 ms and then 90 ms apart, a 12.5 % jump between neighbours that never resolves, because the encoder is buying an impossible rate with two possible ones.

The consequence is worth saying in one sentence: “the frame rate of a GIF” is usually an average that no individual frame has. Any tool that reports a single number for a GIF is reporting something that is not in the file. If you want to know what your GIF really does, you have to look at every delay.

Changing the speed should not touch a pixel

Since the timing lives entirely in those two bytes per frame, retiming a GIF is a byte edit. The palette, the LZW-compressed pixel data, the frame positions, the transparency index — none of it needs to be read, let alone rewritten.

Most GIF speed changers do it the other way round: decode to frames, re-encode, re-quantise the palette. That costs a visible generation of colour every time you touch the file, and it is why a GIF that has been through two or three tools looks worse than the original for no reason anybody can point at.

We measured the byte edit on the 24-frame file above, which is 54,596 bytes:

One byte per frame, not two, for everything except the last row — because the delay’s high byte is zero on both sides of the edit unless the delay crosses 256 centiseconds. Two bytes are written per frame; usually only one of them differs. Either way the file comes back the same length, with the pixel data bit-for-bit identical, which is the property that matters.

Why your browser cannot tell you any of this

The obvious way to check a GIF’s timing is to load it and watch it. It does not work, and the failure is absolute rather than approximate.

We built six copies of the same 12-frame GIF — identical pixels, only the delay bytes rewritten — with delays of 0, 1, 2, 3, 5 and 10 centiseconds. Each was displayed on screen and drawn to a canvas every 4 ms for four seconds, hashing the pixels each time to count how often the frame changed.

Zero advances. On all six files. Drawing an animated GIF to a canvas returns a static frame: the browser will animate the image on screen but will not hand the current frame to your code. That is not a bug we worked around — it is the reason a tool that wants to tell you the truth about a GIF has to parse the file itself.

It also means there is one number we are not going to give you. Browsers enforce their own minimum frame delay, and very small values are treated as something larger — but we could not measure that here, for exactly the reason above, so no figure for it appears anywhere on our pages. Everything else on this page came off a real file.

What to do about it

If you can choose your rate, choose one that exists: 25, 20 or 10 fps are exact, and 25 is close enough to 24 that nobody will see the difference. If you need 30 or 60 exactly, you do not need a GIF — you need a container with a finer timebase, which is the honest reason to convert it to MP4. An MP4 at 30 fps is 30 fps, and it will usually be a fraction of the size.

And if you just want to see what your own GIF is doing, the GIF speed changer draws every frame’s delay as a bar, tells you the exact rate you will get for the rate you asked for, and reports how many bytes it changed to get there. It runs in your browser; nothing is uploaded.

FAQ