GIF Speed Changer

Speed up or slow down an animated GIF by a factor, an exact duration or a frame rate, without changing a single pixel of the picture.

1. 1

   Add your GIF

   Drag an animated GIF onto the drop area, or click to browse. Animated WebP and APNG work too. The file is read on your device and never uploaded.

2. 2

   Pick how you want to say it

   By factor is the usual answer — 2x for twice as fast, 0.5x for half. Choose Duration instead if you know how many seconds the loop has to fill, or Frame rate if every frame should be shown for the same length of time.

3. 3

   Check the speed it will actually reach

   The panel shows the requested speed next to the achieved one. They differ only when a frame would need a delay under 20 milliseconds, which no renderer honours — and when that happens you are told, rather than quietly given something slower.

4. 4

   Download the retimed GIF

   Press Download. For a GIF in, only the timestamps changed: the colour tables, the compressed picture data and the transparency are the bytes that went in.

Almost every GIF arrives at the wrong pace. A screen recording captured at ten frames a second plays like a slideshow when what it needed was to look fluid. A reaction clip cut from video runs so fast the joke lands before anyone reads it. An animation exported from a design tool holds every frame for a tenth of a second because that was the default, not because anyone chose it. Speed is the cheapest correction available in this whole category, because unlike cropping, resizing or compressing, it costs nothing at all: the pictures do not change, only the moment each one appears.

Set a factor, an exact duration or a frame rate, and see the speed actually achieved before you download.

Reads GIF, animated WebP and APNG. A GIF in is re-timed by patching its delay fields, so the colour tables, the compressed picture data and the transparency come out as the bytes that went in.

What re-timing actually buys

• Readability. A demonstration nobody can follow is not a demonstration. Slowing a capture to half speed is often the difference between a clip that explains something and one that only proves it happened.
• Attention. A reaction GIF is a punchline with a rhythm. Two-times is the standard fix for footage cut from real-time video, which is almost always too slow once the context is removed.
• A fixed slot. A loop that has to sit under a slide, beside a heading or inside a video edit has a length it must hit. Duration mode fills it exactly instead of approximately.
• No quality cost whatsoever. Every other edit in this section trades something. Re-timing trades nothing: the picture that comes out is byte-for-byte the picture that went in.

A GIF is a container of length-prefixed blocks. Each frame is preceded by a small Graphic Control Extension that carries its delay in two bytes, and followed by the compressed picture itself. Changing the speed means changing those two bytes per frame, and absolutely nothing else. That is not how online GIF speed tools work: they decode the animation, quantise it to a fresh palette, recompute the frame-to-frame differences and write a new file, because that is what a general image pipeline does with anything handed to it. The result is a picture that has been through a second lossy step for a change that never needed to touch it.

What this tool does instead

• Reads the block structure. The file is walked as blocks, not decoded. That records where every delay field sits, where the loop count sits, and where each frame's compressed data begins and ends.
• Plans the timing. The new delay for every frame is computed while the requested factor is still known, rounded onto the format's own hundredths-of-a-second grid, and clamped to the 20 ms floor renderers enforce.
• Splices, rather than writes. The output is assembled from copied ranges of the original with the delay fields replaced in between. The compressed image data is never read, let alone rewritten.
• Proves it. Each output frame's data span is compared against the input's before the file is handed back, so "the pixels are untouched" is a check the tool performs rather than a claim it makes.

What a speed changer must never change

Two things, and only one of them is obvious. The frame count is the first: a speed change re-times the frames you have and must not silently drop or duplicate any, because a shorter animation played at the same rate looks identical to a faster one until you count. The second is the shape of the timing. Delays in a real GIF are routinely irregular — a held pose, a fast wipe, another held pose — and a tool that replaces them all with one number produces something that plays for the right length of time and is not the same animation. Both are asserted here on every run, per frame rather than in total, because a total can be correct while the distribution is wrong.

A GIF delay is an unsigned count of hundredths of a second. That single detail is behind almost every complaint about GIF speed tools. The achievable set is coarse — 10, 20, 30 milliseconds and so on — so a requested factor rarely lands on a representable value, and where the rounding happens decides whether the request survives. Worse, the bottom of the range is not usable: a delay of 0 or 1 hundredths means "as fast as possible" to every renderer ever written, and they all substitute roughly 100 milliseconds instead. A file asking for 10 milliseconds therefore plays ten times slower than it asked, which is the single most confusing failure in the format.

Measured behaviour

• The real ceiling 20 ms per frame, which is 50 frames per second. A 100 ms source reaches exactly 5x with every frame kept — a 10x request is honestly reported as 5x rather than quietly delivered as one.
• Rounding where it counts A 51 ms frame at 2x becomes 30 ms if the writer rounds last, and 30 ms here too — but the achieved factor, 1.70x, is shown rather than described as 2x.
• Exactness in Duration mode A 1,600 ms animation asked to fill 3,000 ms comes out at 3,000 ms exactly, because the rounding residue is carried from frame to frame instead of being discarded.
• Cost of the lossless path A 20-frame GIF is retimed in single-digit milliseconds and one frame is decoded, whatever the animation's length. Rebuilding the same file takes hundreds of times longer and changes the picture.

Start from the source's own frame rate rather than from a multiplier. A capture holding each frame for 100 milliseconds is running at 10 frames per second, and 2x makes it 20 — smooth enough for most screen content. The same 2x applied to a clip already at 25 frames per second asks for 50, which is the format's ceiling, and 3x asks for something no renderer will honour. The panel shows the source's frame count and total duration before you commit to anything, and shows the speed actually achieved before you download.

By material

• Screen recordings. Usually captured too slowly. 1.5x to 2x is the range that makes a demonstration feel deliberate rather than sluggish. Go further and pointer movement becomes hard to follow.
• Reaction clips cut from video. Usually too slow once the surrounding context is gone. 2x is the default fix; 3x is common and rarely needs anything past it.
• Tutorials and explainers. 0.5x, and check the result rather than the number. A step that was legible at speed is not necessarily legible when each frame lasts twice as long — but a fast wipe usually is.
• Animations with deliberate pauses. Stay in Factor or Duration mode. Frame rate mode will flatten the pauses, and the pauses are usually the point.

• Documentation and READMEs. A recorded workflow at its capture speed is almost always too slow to hold a reader. Speeding it up is the cheapest edit available and costs no quality at all.
• Slides and video edits. A loop that has to fill a known gap. Duration mode fills it exactly, which is the only way to avoid a visible restart part-way through.
• Reaction and meme GIFs. Timing is the joke. A quarter-second too slow and it does not land.
• Emoji and stickers. Small animations play in a small box, and a fast loop reads as motion where a slow one reads as a broken image.

Speeds worth knowing

10 frames per second is a 100 ms delay and the most common default in capture tools. 15 fps is about 70 ms and is the usual compromise for screen content. 20 fps is 50 ms and looks genuinely smooth. 25 fps is 40 ms. 50 fps, a 20 ms delay, is the format's ceiling and the point past which no renderer will go faster. Anything you have seen described as a 60 fps GIF is a 50 fps GIF being optimistic.

The input list is closed and enforced at the file dialog rather than at the engine, so a file this tool cannot open is refused in milliseconds with a route to the tool that can — instead of being accepted and failing later behind a spinner.

• GIF in, GIF out. The lossless path. Animated or single-frame, interlaced or not, GIF87a or GIF89a, with a global palette or a different local palette on every frame — the timing is patched and everything else is copied.
• Animated WebP and APNG in. Both are read by our own demuxers on every browser, so frames and timing are identical everywhere. The output is a GIF, which means this path is a conversion and the picture is rebuilt.
• Files missing their timing blocks. A GIF with no Graphic Control Extension has no delay to change, so one is inserted and a GIF87a header is upgraded to 89a — which is what makes the change legal rather than merely present.
• Anything else is refused with a route. A video is sent to Video to GIF, a still image to the GIF Maker.

What the tool reads

For the lossless path nothing is decoded at all: the file is walked as a sequence of length-prefixed blocks, which is a header read rather than a decompression. Where a rebuild is genuinely needed — a WebP or APNG source, or a request that drops frames — GIF is decoded natively where the browser has a decoder and by our own reader everywhere else, so an animation opens the same way on every engine instead of arriving as its first frame.

Size and batch limits

• Free. One file up to 50 MB, up to 300 frames, up to 2048 pixels on the long edge. Full quality and the same lossless path — the free plan is not a reduced-quality speed change, it is a single-file one.
• Pro. Up to 20 files at once, downloaded as one ZIP, with no imposed frame or dimension cap. Batch is what Pro buys here, because re-timing a folder of captures one at a time is the actual chore.
• The limit both plans share. The format itself. 20 milliseconds is the shortest delay any renderer honours, so no plan can make an animation play faster than 50 frames per second without showing fewer frames.

Nothing is uploaded. For a GIF the file is read once, its block structure is mapped, the new delays are computed and the output is assembled from copied ranges of the original — no decode, no palette, no compression. Where a rebuild is genuinely required the frames are decoded, a palette is built across the whole animation and a standard GIF89a is written out. Either way the work runs in a background thread so the page keeps responding, and the mapping step runs on your graphics hardware where it is available.

Why the result is predictable

• One timing rule, shared. The rounding and the 20 ms floor live in a single function that the reverse and cut tools use as well, so three tools cannot drift into three different ideas of what a delay means.
• The file is read back before it is handed over. The play count and the per-frame delays reported on screen are read out of the finished bytes, not out of the request — the one number a loop control can get wrong is the one it thinks it wrote.
• Checked against another implementation. Output timing is verified with libvips, a completely separate image library, reading the per-frame delay array straight out of the bytes this tool produced.
• A deterministic rebuild. Where re-encoding is unavoidable it uses median cut rather than the randomised quantiser most GIF libraries use, so the same input with the same settings always produces the same output.

For a GIF the whole change is a timestamp patch: one frame decoded, every pixel copied, and the output verified against the input span by span before it is handed back. Where a rebuild is genuinely needed the palette mapping is hardware accelerated on devices that support it, and the accelerated and fallback paths produce byte-identical output. It all runs on your device, not our servers.

• GIF Compressor
• GIF Resizer
• GIF Maker
• Video to GIF
• GIF to MP4
• GIF Editor