Cut GIF

Trim an animated GIF down to the part you want, by frame number or by time, without changing the frames you keep.

1. 1

   Add your animation

   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

   Drag the two handles

   The timeline is built from the animation's own frames, so you can see what you are selecting. Drag either handle, or type exact numbers into the two boxes — they are the same selection, measured in frames or in seconds.

3. 3

   Choose keep, remove or split

   Keep the section between the handles, remove it and join what is left, or ignore the handles and split the whole animation into several shorter ones.

4. 4

   Cut and save

   The result plays on screen with its real frame count and duration, and the card says whether the frames were copied or rebuilt. Save the file, or take every part of a split as one archive.

Most animations you are handed are longer than the part you want. A reaction GIF has three seconds of build-up before the moment that makes it funny. A screen recording captures forty seconds of you finding the button and four seconds of the bug. A loop somebody sent you starts half a beat late, so it never quite loops. Cutting is the most common edit an animation needs, and it is also the one that is easiest to do badly — because the obvious way to do it changes every frame you were trying to keep.

Drag two handles along the animation's own frames to keep a section, remove one from the middle, or split the whole thing into several shorter animations.

Reads GIF, animated WebP and APNG. Writes GIF. The frames you keep are copied out of the original file where its structure allows it, so their colours, their transparency and their per-frame delays are unchanged.

What a cut is usually for

• Trimming the lead-in. Dropping the first second so the loop starts on the movement, which is what makes a short animation read as deliberate rather than as a clip.
• Getting under a size limit. A chat app, a forum or an email signature with a file size cap. Removing frames is by far the cheapest way to shrink an animation, and unlike lowering the colour count it costs nothing at all in the frames that remain.
• Cutting out the dead part. A recording where nothing happens between two useful sections. Removing the middle and joining the ends is a different operation from trimming the ends, and most tools do not offer it.
• Breaking one long clip into pieces. A long capture split into parts that fit a length limit, or into steps for documentation, each one a working animation rather than a folder of pictures.

This is the part worth understanding, because it is what separates this tool from every other one in the category, and because the reason is simple once it is said out loud. A cut removes frames. It does not change the frames it keeps. So there is no reason for the frames it keeps to come out any different from the way they went in — and yet, in every other online GIF cutter, they do.

What a copy actually does

• A GIF is a list of blocks. A header, a colour table, then one block per frame holding that frame's position, its own palette if it has one, its delay, and its compressed picture data. Nothing about a frame's block depends on the file's length.
• So removing frames is removing ranges. The frames you keep are copied out of the original file exactly as they are — the same palettes, the same compressed data, the same transparency, the same offsets. Only each frame's delay field is written fresh, because that is the one number a cut is allowed to change.
• Nothing is decoded. The tool reads the file's structure and copies bytes. It decodes exactly one frame, and only so that the page has something to show you. That is why the copy path is more than ten times quicker than the alternative.
• So the result is not "visually identical". It is the same pixels. Our tests decode the output and the source with a separate image library and require the largest difference on any colour channel of any pixel to be 0 of 255 — equality, not a tolerance.

What re-encoding costs you

The alternative — the one every competing tool takes — is to decode the whole animation, choose 256 colours again from what it finds, map every pixel onto that new palette, recompute which parts of each frame changed, and write a new file. Each of those steps is lossy in a small way, and they accumulate over repeated edits. Measured on our own fixture with a general-purpose encoder standing in for that path, the same three frames come back with colour channels up to four steps away from where they started. Four out of 255 is not a catastrophe on one pass; it is also a change nobody asked for, on a job that had no reason to make one, and it is the third or fourth pass that shows.

When a copy is not possible

A frame in a GIF is not required to be the whole picture. The format lets a frame be a rectangle of any size at any offset, and lets it mark pixels transparent to mean "what is already on screen here is still correct". That is how a screen recording of a mostly-still window compresses so well: frame one is the whole window and frames two onward are small patches. If your cut starts on a patch frame, copying its block alone would produce a file showing that patch on an empty canvas — a valid GIF, a working download, and the wrong picture. So the tool rebuilds instead: it composites every frame onto the full canvas first, then writes them out. Even then it builds the palette out of the colours those frames actually contain rather than choosing new ones, so the result is still exact. The result card always says which of the two happened.

A GIF does not have a timeline. It has a list of frames, and each frame carries its own delay in hundredths of a second. Everything a timeline shows you is derived from adding those delays up, which is why two GIFs of the same length can have completely different frame counts, and why a time you type has to be turned into a set of frames before anything can be cut.

The rule this tool uses

A time span selects every frame that is on screen during it. If frame four runs from 0.60 s to 1.60 s and you ask to keep 0.60 s to 1.70 s, you get frames four, five and six — every picture you could have seen in that span. The best known alternative documents the opposite rule, rounding forward to the next frame boundary, which quietly drops the picture that was on screen at the moment you pointed at. Both are defensible; only one of them never loses something you asked for, and the difference only shows on an animation with irregular delays, which is most of them.

Which unit to work in

• Frames, when you are being exact. Frame numbers are 1-based and inclusive, so 3 to 6 keeps four frames. This is the unit to use when you are cutting to a specific picture — the moment the expression lands, the frame before the artefact appears.
• Seconds, when you are matching something else. A length limit, a beat, a caption that has to stay on screen. The boxes accept two decimal places and the timeline moves with them.
• They are one selection. Switching the unit converts the numbers rather than reinterpreting them, so frames 3 to 6 becomes the seconds those frames occupy and switching back lands on 3 to 6 again. A control that quietly turned "frame 3" into "3 seconds" would be a selection you never made.
• The boxes and the handles agree. Dragging a handle writes the number in the box, in whichever unit is showing. There is no separate drag state, so the picture and the numbers can never disagree about what is going to be cut.

Three things people mean by "cut a GIF", and most tools implement only the first. They are all the same underlying operation — choosing which frames survive — so there is no reason to send anyone to a different page for the other two.

• Keep the selection. The ordinary trim. Everything between the two handles survives and everything outside them goes. This is what a cut means when nobody says otherwise, and it is the default.
• Remove the selection. The inverse. The band between the handles is what goes, and what remains on either side is joined into one animation. The timeline colours the band red so it is obvious which way round you are working.
• Split into parts. Ignore the handles entirely: the whole animation is divided into several shorter animations, by a number of equal parts, by frames per part, or by seconds per part. Each part is a real animation with its own timings, and they download together as one archive.

How the parts are divided

An even split is as even as whole frames allow. Twenty frames into three parts gives seven, seven and six — the remainder is spread across the leading parts rather than dumped on the last one, which is what makes a set of parts look deliberate instead of ragged. Splitting by frames per part gives you parts of exactly that many with a shorter one at the end; splitting by seconds cuts on the animation's own clock, so a part boundary lands between frames rather than inside one. In every mode the parts add back up to the source exactly: no frame is duplicated and none is lost, and the total duration of the parts equals the duration of the animation you started with.

• GIF splitter — one animation in, a folder of still pictures out, one per frame. Use it when you want the images; use this page when you want shorter animations.
• GIF speed changer — the other way to make an animation shorter, by re-timing it rather than by removing frames. Use it when every frame has to stay and only the pace is wrong.

A cut has one obvious job and one that nobody thinks about until it goes wrong. The obvious one is choosing frames. The other is not changing the animation's timing while doing it — and because a GIF stores a delay per frame, there are several ways to get that subtly wrong and still produce a file that plays.

The three timing rules

• A kept frame keeps its own delay. Frame seven had a 40 millisecond delay before the cut, so it has a 40 millisecond delay after it. This sounds too obvious to state, and it is exactly what a tool breaks when it rebuilds an animation at an assumed frame rate.
• The duration out is the sum of what you kept. Not the source's duration, and not a proportion of it. The number on the result card is added up from the delays of the frames in the file you are about to download.
• Only Hold changes a delay. And it changes exactly one: the frame at the seam of a removed section, which is extended by exactly the time that was removed. Everything else comes through untouched.

Shorten or hold, when you remove a section

Removing two seconds from the middle of a five second animation leaves three seconds of pictures, and you have to decide what happens to the two seconds. Shorten is the honest default: the animation is now three seconds long. Hold keeps it at five by leaving the frame before the gap on screen for the missing time, so the animation still takes as long as it did — the pause is visible, but the cadence is preserved. That matters more often than it sounds: a loop timed against a page transition, a countdown that has to stay the same length, an animation sitting in a layout beside another one. Only one browser-based tool in this category exposes the choice at all, and no downloadable one we know of does.

A GIF stores how many times it plays in a small application block near the front of the file. It is easy to miss, and it is stored in an awkward way: the number in the file is how many times to REPEAT after the first play, and zero means forever — so "play exactly once" cannot be written as a number at all, and is expressed by the block not being there.

What that means in practice

• A cut must carry it through. A trimmed animation that plays once and stops, when the original looped, is broken in the way people notice last — usually after it is already published somewhere.
• Rebuilding has to write it fresh. The rebuild path constructs a new file, so the block is written rather than copied. Getting the off-by-one wrong there turns "plays three times" into "plays four times", which is exactly the kind of error that survives review.
• A one-frame result has no loop. Cutting down to a single frame produces a still image, and a still image with a loop block is a contradiction. The block is left out.
• It is tested on three files at once. One that loops forever, one that plays three times, one that plays once — through both the copy path and the rebuild path, with the loop read back out of the finished file by a separate library.

This is the mechanism behind almost everything above, and it is worth one paragraph because it explains why a cut is sometimes a copy and sometimes not, and why cutting a GIF in a naive tool can produce a file that looks broken in a way you cannot explain.

When a GIF is written well, each frame stores only what changed since the frame before it. The rest is marked transparent, which the format defines as "leave what is already there". That is why a 200-frame screen recording of a mostly-still window can be smaller than a 20-frame animation of something that moves. It also means most frames in the middle of such a file are meaningless on their own. A cutter that starts a new animation on one of them produces exactly what you would expect: a small patch floating on an empty canvas, in a file that opens perfectly.

What this tool does about it

• It checks before it copies. A frame can open an animation on its own if it covers the whole canvas and declares no transparency. Every run of frames a cut produces has to begin with one of those, or the copy is refused rather than attempted.
• The check is on the file, not on a guess. It reads the frame's rectangle and its transparency flag straight out of the file — a few bytes, no decoding. The check is deliberately conservative: a frame that declares a transparent colour but never uses one is refused a copy it could have had, which costs a rebuild rather than costing you a broken file.
• A split decides part by part. The first part of a split usually starts at frame one and can be copied; the later parts often cannot. The tool copies the ones it can and rebuilds only the ones it must, rather than dragging the whole job down to the slower path.
• And it tells you. The result card names the path that ran. A tool that quietly re-encoded when it promised not to would look identical from the outside, which is why the path is reported rather than assumed.

Every number below comes from this tool's own test pack on the reference device and is reproducible by running it. Where a claim is about correctness rather than speed it is checked against a separate image library that shares no code with this tool, so the comparison is not our output judged against our own previous output.

The numbers

• Quality On both the copy path and the rebuild path, the largest difference on any colour channel of any pixel between the output and the source frame it came from is 0 of 255. The same frames through a general-purpose encoder come back up to 4 of 255 away.
• Speed Copying is more than ten times quicker than rebuilding the same cut on the same file, measured with the two interleaved so a busy machine cannot flatter one of them.
• Work avoided A copy decodes exactly one frame of the animation, whatever its length — asserted, not estimated. A 100-frame animation is trimmed without ever decompressing 99 of its frames.
• Timing Per-frame delays come through unchanged and the output's total duration is the sum of the kept delays, read back out of the finished file rather than out of the plan that made it.
• Reassembly The parts of a split add back up to the source exactly: the same frame count and the same total duration, with no frame duplicated and none lost.

The input list is closed and it is 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. Animated or single-frame, interlaced or not, with one palette or a different palette on every frame. This is the case where the frames you keep are copied rather than re-encoded.
• Animated WebP and APNG in. Both are read by our own readers on every browser rather than by a native decoder, so frame counts and timings are identical everywhere. They come out as GIF, which is a conversion whatever tool performs it.
• One animation out, or several. Keep and Remove produce one file. Split produces one per part, each a working animation, downloadable individually or together as one archive.
• Anything else is refused with a route. A video is sent to Video to GIF; a still photograph to the GIF Maker. The refusal names what the file is, what this tool takes, and where to go instead.

How the animation is read

On the copy path the animation is barely read at all: the tool walks the file's block structure, which is a few hundred bytes of length-prefixed headers, and never decompresses a picture. On the rebuild path GIF is decoded natively where the browser has a decoder and by our own reader everywhere else, so an animation opens the same way in every browser rather than arriving as its first frame with no error — which is what happens on several browsers without that fallback. Animated WebP and APNG always take our own readers. The tool reports which reader ran, so a difference between browsers shows up as a fact rather than as a mystery.

Plan limits

• Free. One animation up to 200 MB and up to 300 frames, at full quality. The free plan is not a reduced-quality cut — it is exactly the same output, in a smaller batch.
• Pro. Up to 20 animations at a time with no frame limit, cut in one go and downloaded together as one archive. Batch is what Pro buys here, because trimming a folder of clips one at a time is the actual chore.
• The limit both plans share. On the rebuild path every frame is expanded to full colour while it is being worked on, so a memory budget bounds the job before it starts rather than letting the tab stop responding while a progress ring keeps turning. The copy path has no such bound, because it never expands anything.

Nothing is uploaded. The file is read on your own machine, the frames you keep are copied or rebuilt there, and the result is handed straight to your downloads — all in a background thread, so the page keeps painting while the work happens. The tool works with the network disconnected once the page has loaded, and our own tests record every network request made during a run and require the list to be empty.

Why the same cut produces the same file every time

• No randomness anywhere. Nothing in either path uses a randomised algorithm, so the same animation with the same settings always produces byte-identical output. That is what makes it possible to test the result at all.
• The output reports itself. Every file records whether it was copied or rebuilt, and whether its pixels are exact. A silent change of path shows up as a stated fact rather than as an unexplained change in file size.
• Checked against another implementation. Frame identity, frame counts, delays, total durations and loop counts are all verified with libvips — a completely separate image library — rather than against our own previous output.
• The copy is checked against itself, too. After every copy the tool compares the compressed image data in the file it just wrote against the same ranges in the source, byte for byte. It cannot fail, which is exactly why it is cheap to run on every cut and why a future change that broke the guarantee would fail here instead of shipping.

On the copy path a cut never decodes a picture: the tool reads the file's structure and copies the frames you keep, so trimming a 100-frame animation decodes exactly one frame and finishes in single-digit milliseconds. Where the file has to be rebuilt the work runs in a background thread on your graphics hardware where your device supports it, so the page stays responsive. It all runs on your device, not our servers.

• GIF Splitter
• GIF Speed Changer
• GIF Compressor
• GIF Optimizer
• GIF Cropper
• GIF Resizer