GIF Speed Changer
ONLY THE DELAY BYTES CHANGE, NOT ONE PIXEL
Drop an animated GIF here
or click to choose — it is read in your browser, never sent anywhere
Every frame of a GIF carries its own delay, stored in its Graphic Control Extension:
0x21 0xF9 0x04 <packed> <delay lo> <delay hi> <transparent> 0x00
Those two delay bytes are a 16-bit number of hundredths of a second. A whole number. That one detail decides everything else: the only frame rates a GIF can express are 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 … and nothing in between. 30 is not on that list. Neither is 60, nor 24, nor 15.
An encoder asked for 30 fps computes 100/30 = 3.33 centiseconds, cannot store it, and rounds to 3. Your GIF now plays at 33.33 fps. Here is the whole table, and the last column is the one that matters:
| You ask for | Delay stored | It actually plays at | Error | Ten seconds becomes |
|---|---|---|---|---|
| 60 fps | 2 cs | 50.00 fps | −16.67 % | 12.00 s |
| 50 fps | 2 cs | 50.00 fps | exact | 10.00 s |
| 30 fps | 3 cs | 33.33 fps | +11.11 % | 9.00 s |
| 25 fps | 4 cs | 25.00 fps | exact | 10.00 s |
| 24 fps | 4 cs | 25.00 fps | +4.17 % | 9.60 s |
| 20 fps | 5 cs | 20.00 fps | exact | 10.00 s |
| 15 fps | 7 cs | 14.29 fps | −4.76 % | 10.50 s |
| 12 fps | 8 cs | 12.50 fps | +4.17 % | 9.60 s |
| 10 fps | 10 cs | 10.00 fps | exact | 10.00 s |
Ten seconds of video captured at 30 fps is 300 frames. Three centiseconds each is 900 centiseconds — nine seconds. The GIF ends a full second before the clip it came from, and if you are matching it to music or cutting it against a video, that is where the drift comes from. Only 50, 25, 20, 10 and 5 come back exactly.
They do not round every frame the same way. We took an ffmpeg-produced GIF nominally at 12 fps and read its delays straight out of the bytes:
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 fps on average. The average is perfect. But consecutive frames are 80 ms and then 90 ms apart, a 12.5 % jitter between neighbours that never goes away, because the encoder is paying for an impossible rate by alternating two possible ones.
The consequence is worth stating plainly: "the frame rate of a GIF" is usually an average that no individual frame has. A tool that shows you one number is showing you something that is not in the file. This page shows you every delay, as a bar per frame, so you can see whether yours is uniform or dithered.
Here is the part that makes this tool different from every other GIF speed changer. Changing a GIF's speed means writing those two delay bytes per frame. Nothing else. The palette, the LZW-compressed pixel data, the frame positions, the transparency — none of it is involved.
Most tools decode the GIF to frames and re-encode it, which re-quantises the palette and costs a visible generation of colour every time you touch it. This one writes only the two delay bytes of each frame and hands the rest back untouched.
How many bytes actually differ is smaller still, and the page counts them for you rather than promising. We retimed a 24-frame GIF of 54,596 bytes and 24 bytes changed — one per frame, 0.044 % of the file. One rather than two, because the delay’s high byte is zero whenever the delay is under 256 hundredths of a second, so going from 8 to 20 moves a single byte. Ask for a 3.00-second delay and the second byte moves too, and the count becomes 48. Your own file’s number is on the page, next to the file’s total size.
You might expect to read a GIF's timing by loading it and watching it. You cannot. Drawing an animated GIF to a canvas returns a static frame — we tested six files with delays from 1 to 10 centiseconds, sampling every 4 ms for four seconds each, and got zero frame advances on all six. The browser's image decoder will animate a GIF on screen but will not hand its current frame to your code.
So a tool that wants to tell you the truth about a GIF has to read the file itself, which is what this one does, in your browser, without uploading anything.
There is one thing we deliberately do not claim. Browsers also enforce their own minimum delay, and very small values are treated as something larger — but we could not measure that here for the reason above, so no figure for it appears on this page. If you need frame-accurate timing, the answer is not a GIF at all: convert it to MP4, where the timebase is whatever you want it to be.
No. The file is read by your browser, parsed in the page, and the retimed copy is built in memory and handed back to you as a download. It never reaches a server, which is also why it keeps working with the tab offline once the page has loaded.
It cannot. Only the two delay bytes of each frame are written; the palette and the compressed pixel data are copied through untouched. The page reports how many bytes differ between the file you gave it and the file it gives back — for our 24-frame test GIF it was 24 out of 54,596, and if it were re-encoding it would be most of the file.
Because the format stores the delay as a whole number of hundredths of a second, and 100/30 is 3.33. There is no such delay. Three centiseconds gives 33.33 fps and four gives 25. If you need 30, you need a format with a finer timebase — MP4 or WebM.
Almost certainly not. Encoders alternate between two delays to make an impossible average come out right — 8, 9, 8, 8, 9 averages to exactly 12 fps. It is also normal for a hand-made GIF to hold on one frame deliberately. The bar strip on this page shows every delay so you can tell which you are looking at.
It means the file does not specify one, and every viewer decides for itself. That is the one case where you genuinely cannot predict playback, and it is worth setting a real value rather than leaving it. Choose "exact delay per frame" and give it one.
Yes — the speed multiplier goes from 0.25× to 4×, and it divides each frame's existing delay rather than replacing it, so a GIF that was deliberately dithered keeps its relative rhythm. Setting a target frame rate instead makes every frame uniform.
No. The retimed file is exactly the same length as the original, byte for byte, because two bytes are overwritten rather than inserted. If you need a smaller GIF, the lever is the frame count or the palette, not the timing.
Yes. The work is proportional to the number of frames, not the number of pixels, because the pixel data is never decoded. A GIF with hundreds of frames retimes as fast as one with ten.