Change a GIF's speed

Runs in your browser. Nothing is uploaded.

What changing a GIF's speed actually does

A GIF is a stack of frames, and each frame carries a small block of its own settings. Two bytes in that block hold how long the frame stays on screen, counted in hundredths of a second.

Changing the speed of a GIF means changing those two bytes. Every frame keeps its picture, its position and its colours, and the frames stay in the same order. Nothing is decoded on the way in and nothing is re-encoded on the way out, because the pixels are never touched at all.

That is why the output is the same length as the input, byte for byte, apart from the numbers that hold the timing. It is also why the tool is quick: there is no image to redraw, only a few numbers to work out.

Why the file does not get smaller

Most of a GIF's size is the picture data its frames carry. Some tools drop frames, or re-encode each frame with fewer colours; either way they remove some of that data, so the file gets smaller. Both of those also change what the animation shows.

This tool does neither. Every frame is kept, in order, with the same picture and the same colours, so there is nothing for the size to come out of. Speed a GIF up here and the file is exactly as long afterwards as it was before.

If a smaller file is what you need, a speed change is not the way to get it: that is a different job, and not one this page does.

Choosing a speed

The control goes from 0.25× to 4×, and it applies to the whole file at once: there is no per-frame speed, because a GIF has no single frame rate to change. What people pick usually follows what the GIF is for.

What the GIF is forA speed that usually works
A screen recording you want to skim2× to 4×
A slideshow that feels rushed0.5×
A spinner or a progress loop0.25× to 0.5×
Something looping under a caption1×, then crop it

The real ceiling is the file's own shortest wait. A GIF whose frames each wait 1/100 of a second has no room to go faster: half of 1/100 is 0, and GIF has no way to write that. Writing 1/100 instead would make the animation run slower than the speed you asked for, so the tool refuses and names the frame in the way, rather than doing it quietly.

Frames that wait 0, and frames that wait nothing at all

Two kinds of frame come through a speed change untouched, and they are not the same kind.

The first has a settings block, and the wait time in it says 0. There is a number in the file, the number is zero, and each viewer does its own thing with that number. Zero divided by any speed is still zero, so the tool leaves it exactly as it is. Whatever the viewer did with that frame before, it does the same afterwards.

The second kind has no settings block at all. That block is optional in GIF and a file may simply leave it out, which means the file states nothing about how long the frame stays. There is no number to change, so none is changed. This tool never adds a missing block either: adding one would change the length of the file, and keeping the length is the whole promise.

The difference matters when you read the numbers. A file can have three frames whose wait says 0 and two frames with no block at all, and the tool reports those as two separate counts. Calling that "five frames are unaffected" would be true and useless: in one case the file states a zero, and in the other it states nothing, and those are different situations with different explanations.

Every frame that does have a wait is re-timed, all by the same factor, so the pauses keep their proportions instead of some of them changing and others not.

Why the result is within 1/100 of a second, rather than drifting

A GIF stores each frame's wait in hundredths of a second, so every wait in the file has to be a whole number of them. That unit is coarse enough that the way you round it decides whether the animation still lasts as long as you asked for.

The obvious approach is to work out each frame's new wait on its own and round it. That drifts. Every frame can round down a little, and the errors add up: thirty frames each losing a tick is a third of a second gone, and the GIF ends up shorter than the speed you chose, without anything looking wrong.

So the tool works from the clock instead. It scales the running total, then takes the difference between consecutive totals to get each frame's wait. A single frame can still be off by a tick, but the error never accumulates, and the whole animation lands within one tick of the exact answer.

You can see it in the readout. A GIF that waits 110/100 of a second, at 0.7×, has an exact answer of 157.14 ticks. The file can only hold 157, so the readout says 157, and every number there is read back from the file you are about to download rather than calculated for display.

When viewers disagree about very short waits

Some GIFs wait a very short time on each frame, and viewers do not all handle the shortest waits the same way. Some hold such a frame longer than the file asks for; others do not. A GIF built around very short waits can therefore play at slightly different speeds in different browsers and viewers.

Worth knowing when you check your work: the tool reports what the file says, and what you see can differ a little from one viewer to the next. No file can settle that on its own, because the file has already said what it wants and each viewer reads it its own way.

What this tool is not

It is not a compressor. Compressing means taking picture data out, usually by dropping frames or cutting the number of colours, and that does make a file smaller. This tool keeps every frame and every colour, so the size stays where it was.

It is not a resizer either, and it does not convert between formats. No picture enters or leaves the file: a GIF goes in and the same GIF comes out with different timing.

So if the file needs to be smaller, this is the wrong page. If it needs to be a different shape, that is what the GIF cropper on this site does. One more thing it does not do: shorten the animation by removing frames. Nothing is removed, so nothing is lost.

Questions

Does changing the speed change the picture?

No. Nothing is decoded and nothing is re-encoded, so the frame rectangles, the colours and the frame count come through untouched. The only bytes that change are the two that hold each frame's waiting time.

Does the file size change?

Not for a GIF this tool can process: the output is exactly as long as the input, and every byte outside the waiting times is identical. Speeding a GIF up does not make it smaller here. Some tools do shrink a file, because they drop frames, which is a different thing and a different tool.

What speeds can I choose?

Anything from 0.25× to 4×. A choice outside that range is refused as an invalid input rather than answered with a reason that does not apply.

Why can I not go faster than 4×?

The real ceiling depends on the file. A GIF whose frames wait 1/100 of a second each has no room to go faster: half of 1/100 is 0, which GIF cannot express, and writing 1/100 instead would make the animation run slower than the speed you asked for. The tool refuses and says which frame is in the way.

What about frames that wait 0, or have no waiting time at all?

Both are left alone, and they are two different cases. An explicit zero is a wait the file states: 0/100 of a second. A missing block is a file that provides no waiting time for that frame at all. An explicit zero is a delay value, but scaling zero still gives zero. A frame with no delay block has no value to change at all. The tool counts the two separately rather than merging them. Viewers may apply a minimum of their own to the shortest waits, so what you see can differ a little between them.

Does my file get uploaded?

The selected GIF is processed locally in your browser and is not uploaded. Once the page has loaded, changing its speed does not require sending the GIF to a server.

Is the output identical to the input?

Not byte for byte: the waiting times hold different numbers, which is the point. Everything else is byte for byte the same, and the picture is unchanged.

Why does the result say it is within 1/100 of a second?

Because a GIF stores each frame's waiting time in hundredths of a second. The tool works out each frame's share from the running total rather than rounding each one on its own, so the whole animation stays within about 1/100 of a second of the exact answer instead of drifting as frame count grows.