GIF Frame Rate Guide: Why 15 fps Usually Beats 30
June 12, 2026
Pick the wrong frame rate and your GIF is either twice as big as it needs to be or visibly choppy. Pick the right one and nobody notices the frame rate at all, which is the goal. This guide covers how GIF timing actually works under the hood, why browsers silently rewrite some delay values, and which fps to use for which job, with real size numbers.
The short version: 15 fps is the sweet spot for most clips, 10 fps is fine for screen recordings, and 30 fps is usually a waste of bytes that GIF can’t even represent exactly.
GIFs don’t have a frame rate
This sounds pedantic but it explains most of the weird behavior you’ll hit. A GIF file has no global “fps” field. Each frame carries its own delay in the Graphic Control Extension, and per the GIF89a specification that delay is measured in hundredths of a second (centiseconds), stored as a 16-bit integer.
That 10ms granularity means many common frame rates literally cannot be encoded:
| Target fps | Exact delay needed | Closest centisecond delay | Actual fps you get |
|---|---|---|---|
| 50 | 20 ms | 2 (20 ms) | 50.0 |
| 33.3 | 30 ms | 3 (30 ms) | 33.3 |
| 30 | 33.3 ms | 3 (30 ms) | 33.3 |
| 25 | 40 ms | 4 (40 ms) | 25.0 |
| 24 | 41.7 ms | 4 (40 ms) | 25.0 |
| 20 | 50 ms | 5 (50 ms) | 20.0 |
| 15 | 66.7 ms | 7 (70 ms) | 14.3 |
| 12.5 | 80 ms | 8 (80 ms) | 12.5 |
| 10 | 100 ms | 10 (100 ms) | 10.0 |
So a “30 fps GIF” actually plays at 33.3 fps, and a “15 fps GIF” plays at 14.3 fps, unless the encoder alternates delays (6, 7, 7, 6, 7, 7…) to average out to the target. Good encoders do this; many don’t. If your converted GIF seems to drift out of sync with the source audio in your head, this is why.
The browser clamp: never use delays under 20 ms
Here’s the trap that bites people trying to make ultra-smooth GIFs. If a frame specifies a delay of 0 or 1 centisecond (0 or 10 ms), browsers don’t honor it. They clamp it up to 100 ms, dropping your intended 100 fps GIF to 10 fps.
This isn’t a bug, it’s deliberate. The Chromium source comments that “many annoying ads specify a 0 duration to make an image flash as quickly as possible,” so Chrome follows Firefox and uses 100 ms for any frame with a delay ≤ 10 ms (documented in detail in The Fastest GIF Does Not Exist). Firefox has behaved this way since the early 2000s, partly to match old Netscape timing that broken authoring tools depended on (Mozilla bug 232822).
A cross-browser study confirmed no major browser renders delays below 0.02 s. The practical rules:
- Minimum usable delay: 2 centiseconds (20 ms), i.e. 50 fps. That’s the hard ceiling for GIF playback in browsers.
- Delays of 0 or 10 ms play at 10 fps, not fast. A “60 fps” GIF (16.7 ms delay, rounds to 1 or 2) is either a 50 fps GIF or a 10 fps disaster depending on which way the encoder rounded.
If you genuinely need 60 fps, GIF is the wrong container. Convert it the other way with a GIF to MP4 tool; an MP4 will be smaller and smoother.
Why 15 fps looks better than you’d expect
Film runs at 24 fps and looks smooth. GIFs at 15 fps often look fine too, for three reasons:
- Source footage carries motion blur. Each video frame already smears fast motion across its exposure time. When you drop every other frame, the blur in the remaining frames keeps motion looking continuous. This is why downsampled camera footage degrades gracefully while synthetic content (cursor movements, CSS animations) gets choppy faster.
- GIFs are small and looping. On a 320–480px clip that loops every few seconds, your eye locks onto the content, not the cadence. Judder that would be obvious on a fullscreen 10-second video reads as “normal GIF” at meme size. The loop also means viewers see it multiple times and stop noticing temporal artifacts after the first pass.
- The palette hurts more than the frame rate. GIF caps you at 256 colors per frame. Banding in gradients and dither noise are far more visible than the difference between 15 and 25 fps. Spending your byte budget on resolution or a cleaner palette beats spending it on frames almost every time.
The exception is fast, small-detail motion with sharp edges: gameplay clips, sports, anything with quick pans. There, 15 fps shows visible stepping and 20–25 fps is worth the cost.
File size scales roughly linearly with frame rate
GIF compresses each frame with LZW, and most encoders also do frame differencing (only storing pixels that changed since the previous frame). For typical video content, lots of pixels change every frame, so doubling the frame count roughly doubles the file size. For static-background content like screen recordings, differencing absorbs some of the cost, so going from 10 to 20 fps might only add 50–70% rather than 100%.
Ballpark numbers for a 10-second, 480px-wide clip of normal video footage (moderate motion, decent encoder, 256-color palette):
| Frame rate | Approx. size | Notes |
|---|---|---|
| 10 fps | 3–5 MB | Fine for UI demos, choppy for video |
| 15 fps | 4–8 MB | Sweet spot for most content |
| 20 fps | 6–10 MB | Smooth motion, noticeably bigger |
| 25 fps | 8–13 MB | Near-ceiling smoothness |
| 33 fps (“30”) | 10–17 MB | Rarely worth it |
Content matters enormously here: a talking-head clip can land at half these numbers, confetti or water can double them. But the ratio between rows holds. Going from 15 to 30 fps roughly doubles your size for a smoothness gain most viewers won’t register at GIF dimensions.
If you’re over a platform limit, dropping frame rate is the second-best lever after dimensions. A GIF compressor that supports frame dropping can take an existing 30 fps GIF down to 15 fps without re-encoding from source, and lossy LZW plus palette reduction can claw back another 30–60% on top.
Which frame rate for which job
| Use case | Recommended fps | Why |
|---|---|---|
| UI/product demos, terminal recordings | 10–12 | Mostly static frames; differencing makes these tiny. Cursor motion at 10 fps is completely readable. |
| Tutorials with scrolling | 12–15 | Scrolling at 10 fps strobes; 15 smooths it out. |
| Reaction GIFs, memes from video | 12–15 | Source motion blur does the work. Nobody has ever judged a meme’s frame pacing. |
| Sports, gameplay, fast camera pans | 20–25 | Sharp synthetic edges and fast motion expose stepping below 20. |
| Slow-mo or cinemagraph-style loops | 15–25 | Depends on how slow; slower apparent motion tolerates lower fps. |
| Anything needing 30+ fps | Use MP4/WebM | GIF can’t represent 30 exactly and the size is brutal. |
When converting, set the frame rate at conversion time rather than generating at 30+ and reducing later, since the encoder can then build the palette and frame diffs against the frames that will actually ship. A video to GIF converter with an fps control and a live size estimate makes the tradeoff concrete before you export. GIF Den does this conversion entirely in your browser via WebCodecs, so you can iterate on fps settings without re-uploading anything (the file never leaves your machine — here’s how to verify that).
Quick reference
- GIF delays are in centiseconds; 15, 24, and 30 fps don’t encode exactly. Expect 14.3, 25, and 33.3, or alternating delays.
- Never go below a 20 ms delay. Browsers clamp 0–10 ms delays to 100 ms, turning your fast GIF into a 10 fps one.
- The browser-playable ceiling is 50 fps (delay = 2). Past 25 fps you’re paying double for smoothness nobody sees at GIF sizes.
- Size scales ~linearly with fps for video content; less than linearly for screen recordings.
- Defaults that rarely fail: 10–12 fps for screen captures, 15 fps for video clips, 20–25 fps only for fast motion.
- Still too big at the right fps? Cut dimensions first, then trim the loop, then reach for lossy compression.