The delay between frames is what actually gives a GIF its speed — a shorter delay plays faster, a longer one plays slower. That relationship holds true right up until the delay gets extremely short, at which point a long-standing quirk in how GIFs get decoded starts working against the setting entirely.
How GIF Timing Actually Works
The GIF format stores each frame's delay in units of 1/100th of a second — a centisecond. A 500-millisecond delay becomes 50 centiseconds internally; 1000 milliseconds becomes 100. The conversion rounds to the nearest centisecond, so a delay like 105ms comes out to 11 (not 10) once stored.
The Problem With Very Short Delays
Once a delay rounds down to 1 centisecond (10 milliseconds) or less, many GIF viewers and browsers historically ignore the stored value entirely and fall back to a default playback speed — commonly around 100 milliseconds per frame — regardless of what was actually set. This isn't a bug in any one tool; it's a widespread, long-standing convention across the GIF decoding ecosystem, dating back to how early browsers handled edge cases in the format.
The practical result: setting a delay of 5ms expecting a very fast, near-instant flicker between frames can end up playing noticeably slower than intended, because the actual stored value falls into the range many viewers disregard.
What This Means Practically
Staying above roughly 20 milliseconds per frame keeps playback speed predictable across the widest range of viewers and platforms. For anything faster than that — genuinely rapid flickering effects — it's worth testing the resulting GIF in more than one viewer before relying on the exact timing, since behavior at the very low end isn't fully consistent everywhere.
Set your timing with a warning before you export
Try the Online GIF Maker