GIF Speed Changer
Changing a GIF's speed is arithmetic with one awkward fact in the middle of it. A GIF stores each frame's delay in hundredths of a second, so the only delays that exist are multiples of 10 ms: scale an 80 ms frame by 3 and the 26.67 ms you asked for is written as 30 ms. This tool does that rounding itself and prints what comes out of it, so the length beside the result is the length the file will really run for rather than the one the multiplication promised. Ask by factor, from 0.25x to 4x, or type the length the finished GIF should run and the factor is worked out for you. No frame is dropped or duplicated: the frame count out always matches the frame count in, and only the delays change. A frame whose scaled delay would fall under 10 ms is held at the 10 ms floor rather than written as no delay at all, and the page says how many frames that happened to and the speed the file therefore plays at. Delays under 20 ms get one more warning, because many browsers refuse a delay that short and play it at about 100 ms instead, which turns a legal fast GIF into a slow one on screen. The loop setting is read from the file and written back unchanged, nothing is uploaded, and there is no account.
Drop a GIF here, or choose one below.
Open a GIF and its delays, duration and loop setting are read out here.
Every frame is decoded, retimed and written again in this tab.
Every delay is divided by the factor and rounded to the 10 ms step a GIF stores.
· or drop one anywhere on the stage
No GIF open yet. Choose one, or drop it on the stage.
A GIF stores each frame's delay in hundredths of a second, so every scaled delay lands on the 10 ms step, and a delay that would fall under it is held at 10 ms rather than written as none. Many browsers refuse a delay under 20 ms and play it at about 100 ms instead. The loop setting is read from the file and written back unchanged. The ceilings are 600 frames, 25 million pixels in one frame and 150 million across the animation, because the decoder hands every frame to this tab at once.
Common questions
- How do I make a GIF play faster or slower?
- Open the GIF and choose a factor: 2 plays it twice as fast, 0.5 plays it half as fast, and anything from 0.25x to 4x is written in one pass. Every frame's delay is divided by that factor, so a file of 80 ms frames becomes a file of 40 ms frames at 2x. Nothing is dropped and nothing is repeated, which is why the frame count beside the result always matches the one you opened. The new file is written here, in this browser tab, and Download GIF saves it. To go beyond 4x, run the file the tool writes through it a second time.
- Why is the finished GIF not exactly the length I asked for?
- Because a GIF stores a frame delay in hundredths of a second, so 10 ms is the only step it has. Three frames of 100 ms at 3x want 33.33 ms each, which the file cannot hold: each one is written as 30 ms and the animation runs 0.09 s rather than the 0.1 s the factor alone would give. The tool rounds to the nearest step, reports how many frames moved and by how much the total moved, and prints the duration that comes out of the rounding. That is why the length on the page is the length you will actually get.
- Can I set an exact length instead of a speed?
- Yes. Switch to Target length and type how long the finished GIF should run, in seconds, and the factor is worked out from the length the file has now. Because the tool writes 0.25x to 4x in one pass, a GIF that runs 3.84 s reaches 0.96 s at the fast end and 15.36 s at the slow end, and the page names that window under the field. A target outside it is refused with both numbers rather than quietly clamped, and the delays are still rounded to the 10 ms step afterwards, so the result can land a hundredth or two away from the target.
- What is the fastest a GIF can be made?
- 10 ms a frame, because that is the shortest delay the format can store. If a scaled delay would fall under it, the frame is held at 10 ms rather than written as no delay at all, and the page counts those frames and prints the speed the file really plays at: 20 ms frames asked to go 4x come out at 10 ms, which is 2x. Going further means dropping frames, which is a different job and would change the animation, so this tool does not do it quietly.
- Why does my fast GIF still look slow in a browser?
- Many browsers refuse a frame delay under about 20 ms and play it at roughly 100 ms instead, a rule inherited from very old animated GIFs that set no delay at all. So a file that legitimately stores 10 ms frames can play ten times slower than it says. The tool counts the frames under 20 ms and shows the duration that behaviour produces beside the duration the file stores, so you can choose a gentler factor before you download rather than wonder afterwards.
- Does changing the speed lose quality or break transparency?
- The timing is exact and the pixels are re-encoded. Each frame is composited forward with its transparency and disposal rule applied, so the file is rebuilt from whole pictures rather than the small changed rectangles the original stored, which is what stops a rewritten GIF smearing. Each output frame then gets a fresh 256 colour palette, the most a GIF frame can hold, so a large flat area or a soft gradient can shift by a shade. Transparency is a single bit in a GIF, so a partly see-through pixel lands on either fully clear or fully solid.
- Is my GIF uploaded anywhere?
- No. The file is read by a JavaScript GIF decoder running in this tab, retimed by this page's own code and written back out by a JavaScript GIF encoder here. There is no upload, no queue, no account and no request of any kind: no byte of the animation reaches a server, an analytics call or an error report. The only thing kept between visits is the factor, the mode and the target length you last used, stored in this browser, and the Start over button above clears it.
- Are there any size limits, and does the loop setting survive?
- The loop block is read from the file and written back unchanged, so a GIF that loops forever still loops forever and one that plays once is never handed back looping. The limits are memory, not policy: 600 frames, 25 million pixels in a single frame, which is roughly 5000 by 5000, and 150 million pixels across the whole animation, because the decoder hands every frame to this tab at once. A file over any of the three is refused with the number it actually reached instead of a frozen tab, and a long run has a Cancel button that really stops it.
Frame delays are scaled and then rounded to the 10 millisecond step a GIF file can store, so the page prints the duration you will really get rather than the one you asked for. Many browsers also refuse delays under about 20 milliseconds and play them slower.