GIF Reverser

Play an animated GIF backwards, turn it into a boomerang, or reverse just a section of it — with the timing mirrored rather than rewritten.

1. 1

   Add your GIF

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

2. 2

   Choose backwards or boomerang

   Reverse plays the animation from the last frame to the first. Boomerang plays it forward and then back to the start, dropping the two turn frames so no picture is ever shown twice in a row.

3. 3

   Reverse everything, or just a range

   By default the whole animation flips. Switch to a range and give a first and last frame to reverse only that section — everything outside it keeps its place and its order.

4. 4

   Download the reversed GIF

   Press Download. When the source allows it, the panel says the frames were copied rather than redrawn: the colour tables, the compressed picture data and the transparency are the bytes that went in.

A reversed animation is not just a novelty. Running a clip backwards is how a jump cut becomes a loop, how a build-up becomes a reveal, and how a five-frame reaction becomes something that plays forever without a visible seam. It is also the quickest way to test whether an animation's motion reads clearly, because a movement that only makes sense in one direction usually has a timing problem you had not noticed.

Play an animated GIF backwards, build a boomerang loop, or reverse just a range of frames — with each frame keeping its own delay so the timing mirrors exactly.

Where the file allows it the frames are copied out in the new order rather than redrawn, so the palette, the compressed picture data and the transparency are the bytes that went in.

What this tool does that the alternatives do not

• Nothing is redrawn where nothing needs to be. Frame order is a property of the container, not of the picture. When the file allows it, the frames' compressed bytes are copied out in the new order and everything else is copied verbatim.
• The timing mirrors, it does not flatten. Each frame keeps its own delay, so an animation with a long hold at the end comes back with a long hold at the start — which is what a mirror is.
• Delta frames are detected, not ignored. An optimised GIF whose frames are patches over their predecessors is composited first. Reversing those patches directly produces a file that opens and renders as garbage.
• Boomerang without the stutter. The forward and return legs share their endpoints, so the turn and the loop point are both clean.
• A range, not just the whole thing. Reverse frames 12 to 40 and leave the rest alone.
• Nothing is uploaded. The whole job runs on your device, so there is no queue, no retention window and no file to delete afterwards.

A GIF file is a header, a colour table, and then a run of blocks. Each frame in that run is a self-contained sequence of bytes: an optional graphic control extension carrying the frame's delay and disposal method, an image descriptor carrying its rectangle, an optional colour table of its own, and the compressed picture data. Nothing in a frame's bytes refers to its position in the file. So reversing the animation can be exactly what it sounds like — take those runs, write them out in the opposite order, copy every other byte as it was.

What the fast path actually does

• Walk the blocks. The file is scanned once as a structure — length-prefixed blocks, no decompression — recording where each frame's bytes begin and end.
• Check that the order is free to change. Every frame's rectangle, transparency flag and disposal method is read. The reorder only runs when each frame is provably independent of the one before it.
• Copy the runs in the new order. The output is built as a list of copied ranges from the input, with the header, the global colour table and the trailer left exactly where they were.
• Prove it afterwards. Each output frame's compressed data and delay are compared byte for byte against the source frame it came from. That check runs on every reversal, because the guarantee is cheap to verify and expensive to lose.

The invariant that is easy to get wrong

A reversal must not change the total playing time, must not change the frame count, and must not change which delay belongs to which picture. The first two are obvious enough that most tools get them right. The third is the one that quietly fails: if a tool reverses the frames but leaves the delay array alone, every number is still there, the total is still correct, and the animation is wrong — the pause that used to sit on the final frame now sits on the first. Here the delay is read out of the frame's own bytes and travels with it, which makes the mirror exact by construction rather than by arithmetic.

Most GIFs you will meet are optimised. Instead of storing every frame as a full picture, an encoder stores frame twelve as the small rectangle of pixels that actually changed since frame eleven, marks the unchanged pixels transparent, and sets a disposal method telling the renderer what to do with that rectangle before the next frame arrives. It is an enormous saving — on a static background with one moving square, storing whole frames costs 122,414 bytes and storing differences costs 7,064 — and it is why a naive reversal is dangerous rather than merely imperfect.

The three ways a reversed frame can be wrong

• A sub-rectangle in the wrong place. A patch is meaningful only over the picture it was computed against. Reversed, every patch lands on the wrong base image, and the result is the familiar smeared, half-drawn mess people report as a corrupted GIF.
• Transparency that means "keep what was there". In a delta frame, transparent does not mean invisible — it means the previous frame's pixel is still correct. Reverse the order and that statement is false for every frame.
• Restore to previous, which has no backwards form. Disposal method 3 is defined purely in terms of what came before it. There is no way to remap it through a reversal; the animation has to be composited and rebuilt.

When the frames may be moved, and when they may not

The rule this tool applies is checked, never guessed. Frames may be reordered when every one of them covers the whole canvas and is fully opaque — because then each frame overwrites everything before it, whatever the disposal says — or when every one of them covers the whole canvas and is cleared to the background before the next arrives, because then each frame renders against the same blank. Anything else, including an extension block sitting between two frames, sends the animation down the composite path: it is decoded into full pictures, reordered, and re-encoded with fresh differences computed for the new order. That is slower and it re-quantises the palette, and it is the only correct answer. The tool names which path ran and, when it rebuilt, says why.

A boomerang plays the animation forward and then backwards, so the last frame of the cycle sits next to the first and the loop has no seam. It is the reason most people reach for a reverser in the first place, and it is where the arithmetic quietly goes wrong.

The two duplicate frames nobody removes

• At the turn. Forward ends on the last frame; the return leg starts on the last frame. Written naively, that picture is shown twice in a row and the motion visibly hesitates before it comes back.
• At the loop point. The return leg ends on the first frame; the next cycle starts on the first frame. Same hesitation, once per loop, forever.
• The fix is two frames. Drop the endpoints from the return leg. An eight-frame animation becomes fourteen frames rather than sixteen, and no picture is ever displayed twice consecutively — including across the loop boundary.

What it costs

A boomerang is close to twice the animation, so it is close to twice the file. There is no way around that: the extra frames are real frames and they have to be stored. What can be avoided is storing more of them than the effect needs, and two frames per cycle is what a careless implementation adds. On the copy path the return leg costs exactly what the forward leg cost, because it is the same compressed bytes written a second time.

Sometimes the whole clip should not run backwards. A screen recording with a title card at the start, a reaction with a beat of stillness before the movement, a product spin with a static hero frame at each end — in all of those the interesting motion is a section, and reversing the file wholesale moves furniture that was fine where it was.

How the range behaves

• Frames outside the range do not move. They keep their positions and their order. A range reversal is a local edit, not a rearrangement of the timeline.
• The range is inclusive and one-based. Frames 4 to 9 means the fourth through the ninth, counted the way the frame readout counts them.
• Boomerang respects it too. Set a range and choose boomerang, and only that section runs forward-then-back — the frames around it play once, as they did.
• A one-frame range changes nothing, and says so. Rather than handing back a copy of the file, the tool tells you the frame order it is about to write is the order it read.

How many times a GIF plays is not stored as a number of plays. It lives in an application extension block that carries a repeat count, where the count is the number of times to play AGAIN after the first pass, and zero is reserved to mean forever. So a file that says 2 plays three times, a file that says 0 plays endlessly, and a file that plays exactly once cannot say so at all — it expresses that by not carrying the block.

• Keep is the default. The file's own looping is left untouched, including the play-once case, which a tool that always writes a count would silently convert into an endless loop.
• Forever, once, or a number. Choose in terms of plays — how many times the animation runs — and the correct one of those three encodings is written for you.
• The result is read back out of the file. The number shown after a reversal is measured from the finished bytes, not from the request, because the one number a loop control can get wrong is the one it thinks it wrote.

• Seamless loops. A clip that ends somewhere other than where it started jumps every time it repeats. Boomerang removes the jump without asking the source to be perfect.
• Reveals and undo. Running a build-up backwards turns it into a teardown, which is the cheapest way to get a matching pair of animations out of one recording.
• Reaction clips. A short reaction usually reads better as a ping-pong than as a hard loop, and it is two seconds of work rather than a re-edit.
• Product spins. Reversing the back half of a turntable makes an object rock rather than spin, which loops cleanly at any length.
• Checking your own timing. Motion that only reads in one direction almost always has an easing or hold problem. Reversing it is a fast diagnostic.

What happens to the file size

On the copy path, nothing: the output is the same compressed frames in a different order, so it is within a byte or two of the source. On the rebuild path the size moves, and it can move either way — a palette built across the whole animation compresses differently, and the frame-to-frame differences of a reversed animation are genuinely different data from those of the original. Boomerang mode roughly doubles the file wherever it runs, because it stores almost twice as many frames. If the result needs to be smaller, the GIF Compressor can solve directly for a size you name.

The input list is short and it is enforced at the file picker, so nothing is accepted that cannot be opened. A file of the wrong kind is refused immediately, with a link to the tool that does handle it, rather than being queued behind a spinner that eventually fails.

• GIF in, GIF out. The only combination that can take the copy path, and the one where the picture is provably untouched.
• Animated WebP in, GIF out. Decoded and rebuilt. Frame order and timing follow the same rules; the pixels are re-encoded because they have to be.
• APNG in, GIF out. The same, including files served as image/png, which is how most systems label an APNG.
• Still images and video are refused. With a route: the GIF Maker for a still, Video to GIF for a clip.

How the animation is read

Where the browser provides an animated image decoder, it is used. Where it does not, the tool falls back to its own reader, which walks the container and decompresses the frames itself — that is what makes animated GIFs work here in browsers that would otherwise hand back a single still frame with no error at all. Frames are composited as they are decoded, so each one arrives as a complete picture with its disposal method already applied. On the copy path none of that runs: the file's structure is read, the frames are moved, and not a single pixel is decompressed.

Limits, and where they come from

• Free: 50 MB, one file at a time. Up to 300 frames and 2,048 px on the longest edge, at full quality and down the same lossless path Pro uses.
• Pro: up to 20 GIFs at once. Frame count and dimensions unlimited, size limited by what your device's memory can hold, and the whole batch downloaded as one ZIP.
• The caps are policy, not capability. Nothing about the format or the device makes 300 frames a boundary; it is where the free plan stops.
• Memory is a real ceiling. The rebuild path holds decoded frames, and 500 frames at 1920 by 1080 is several gigabytes. Work is bounded before it starts rather than discovered halfway through.

There is no upload step, no queue and no server rendering the result. The file is read where it is, the work runs in a background thread so the page stays responsive, and the finished animation is handed straight back to the download button.

The path a file takes

• Read the structure. A header read tells the tool how many frames the file has, how long each one runs, and whether its frames may be reordered. Nothing is decompressed for this.
• Decide the path, before any work starts. If the frames may be moved, the animation is never decoded at all — the reversal is a copy. If they may not, the whole animation is decoded and composited.
• Do the job off the main thread. Decoding, compositing, palette building and compression all run in a worker, so the progress indicator keeps moving because the page is genuinely still responsive.
• Report what actually happened. The path that ran, the frame count in and out, the delays that were written and the number of plays are all read back from the finished file.

On a mid-range laptop, a 100-frame 480 by 270 animation is reversed by the copy path in a few milliseconds, because the work is proportional to the number of blocks in the file rather than to the number of pixels in it. The same file rebuilt — which is what every other tool in this category does to every file — takes roughly two orders of magnitude longer and returns a different picture.

• GIF Speed Changer
• GIF Cutter
• GIF Splitter
• GIF Compressor
• GIF Editor
• Video to GIF