Optimize GIF

Remove the redundancy between an animated GIF's frames without changing its size, its speed or its colours.

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

   Leave the defaults for a lossless pass

   Frame differencing is on and duplicate frames are removed only when they are byte-identical. Nothing about the picture changes on these settings — the file simply stops storing what it already stored.

3. 3

   Reach for a slider only if you need more

   Difference tolerance forgives near-identical pixels between frames. Lossy runs joins near-identical pixels within a frame. Both trade a little accuracy for real size, and both show you exactly what they cost.

4. 4

   Check the report, then download

   The result panel names the frames kept, the share of the canvas each stored frame covers and the duration in and out. Press Download when the numbers say what you wanted.

Almost every GIF in circulation is larger than it needs to be for a reason that has nothing to do with quality. The format has allowed a frame to cover only the rectangle that changed since 1989, and to mark the rest of its pixels as "what is already on screen here is still correct" — and most encoders never use either. So a twenty-frame screen recording of a static page with a moving cursor stores that static page twenty times. Optimising removes the repetition and touches nothing else: the same dimensions, the same number of frames a viewer sees, the same playback speed and, on the default settings, the same colours down to the last value.

Store only the pixels that change between frames, delete frames that repeat and merge their time into the frame that stays, and share one colour table across the animation.

Reads GIF, animated WebP and APNG. Writes a standard GIF89a at the same dimensions, the same duration and — where the palette fits — the same colours.

What that is worth, measured

• Frame differencing. On this tool's reference animation — a gradient background with one small square crossing it — 196,091 bytes stored whole becomes 48,131 stored as differences. On the hundred-frame version, 4,776,638 becomes 1,172,755. Both are 4.07x, and both are colour-exact.
• Duplicate frames. A twelve-frame animation of four distinct pictures comes out as four frames carrying the same twelve frames' worth of time. A six-frame animation of one picture comes out as one frame holding all 600 ms.
• Cropping a see-through frame. A sticker whose opaque content fills a fifth of the canvas is stored as a fifth of the canvas. On this pack's transparent test animation that is 191 bytes from 19,473 — a hundred-fold reduction with the transparency intact.
• Nothing you did not ask for. No resize, no frame-rate cut, no palette reduction unless you move a slider. If re-encoding cannot beat the file you gave us, you get your file back and are told so.

A GIF is not a stack of pictures. It is a canvas plus a list of instructions, and each instruction is allowed to paint a rectangle anywhere on that canvas, at any size, with any of its pixels marked see-through so that whatever is underneath shows instead. A frame that changes a 30-pixel patch can be stored as a 30-pixel patch. The reason so few files do this is that writing one is much harder than writing the other: the encoder has to keep a model of what a decoder would currently be showing, compare against that rather than against the previous source frame, and get the disposal method right or the result smears. It is easier to write every frame whole, so most encoders do.

What happens to each frame

• Composite. Every frame is drawn onto a canvas of the animation's logical size, honouring its offset, its disposal method and its transparency, so what gets compared is the picture a viewer would actually see rather than the patch that was stored.
• Scan once. A single pass answers everything the encode needs: which frames are repeats, whether there is any transparency anywhere, how many distinct colours there are, and the sample the palette is built from. Answering them separately would mean four passes over every pixel.
• Map to one shared table. Where the source's colours fit a table, that exact list becomes the palette. Where they do not, one is derived across the whole animation rather than from the first frame, so colours do not shift as it plays.
• Difference, then compress runs. Each frame is compared against a running model of the decoded canvas, reduced to the rectangle that changed, and the unchanged pixels inside that rectangle are marked see-through. Only then does the optional lossy pass run, so it can never damage the difference.

The invariant every implementation of this gets wrong

When a duplicate frame is removed, its display time has to go somewhere. Drop ten frames of a twenty-frame animation at 100 ms each and forget to merge the delays, and you are left with ten frames of 100 ms — a two-second animation that plays in one second, at double speed. The output is a valid GIF. Nothing errors. It simply is not the animation that went in. Here the total duration in and the total duration out are compared on every run and a mismatch is raised as an error rather than returned as a smaller file, and both numbers are printed on the result panel so you never have to take it on trust.

Content-based frame removal is different from dropping every second frame, and the difference is the whole point. Dropping every Nth frame is blind: it removes frames that showed something new alongside frames that did not, and the result stutters immediately. Removing duplicates only deletes frames a viewer could not have distinguished from the one before, and merges their time into it — so a screen recording where the cursor pauses for half a second loses ten stored frames and none of its motion. If what you want instead is a lower frame rate, that lever lives on the compressor, where it belongs alongside the other quality trades.

Two modes, and the threshold that separates them

• Identical only. Byte-for-byte repeats, and nothing else. This is the default because it cannot change what anyone sees — the frames being removed were, pixel for pixel, already on screen.
• Near-identical. A similarity threshold from 80% to 100%. At 98%, a frame matching at least 98% of the previous kept frame is treated as a repeat. Useful on footage with faint noise, where nothing is ever byte-identical and a great deal is visually unchanged.
• Off. Every frame is kept whatever it holds. Worth choosing when the frame count itself matters — some editors and some sprite pipelines index frames by number.

Why the comparison is against the last frame kept

Compare each frame against the one immediately before it and a slow fade passes the threshold at every single step, so the whole animation collapses to its first frame while every individual comparison looked perfectly reasonable. Comparing against the last frame that was KEPT bounds the error instead: whatever the threshold is, that is the most a viewer can ever be shown that the recording did not contain, and it does not accumulate. It is a smaller number of frames removed on drifting material and it is the right trade, because the failure it prevents is silent.

Every number below comes from this tool's own test pack, on fixtures committed alongside it and regenerated by a script rather than checked in as mysterious binaries. Each output is read back by three independent implementations: libvips for the rendered animation, gifsicle for the frame structure, and a structural reader written for the pack that walks the file's blocks and never runs the decompressor.

The levers, in order of what they are worth

• Frame differencing 4.07x on the reference animation at both 20 and 100 frames, with a measured mean colour error of 0.000 of 255. This is the whole reason the tool exists.
• Duplicate removal 12 frames to 4, and 6 to 1, on the two dedicated fixtures — with 1,200 ms in and 1,200 ms out, and 600 ms in and 600 ms out.
• Difference tolerance at 40 1,172,755 bytes to 487,196 on the hundred-frame reference. A further 2.41x on top of the lossless pass.
• Lossy runs at 60 1,172,755 bytes to 478,644 on the same file. Comparable to the tolerance slider and visible in a different way — within a frame rather than across frames.
• Speed A hundred frames at 480x270, decoded, scanned, differenced and written, in 252 to 380 ms on the reference device.

Against gifsicle, the engine most online optimizers run

The frame rectangles this tool produces are identical to gifsicle -O3's on every fixture measured — same offsets, same sizes, same colour-table sizes — which says the structural decisions agree. On total file size we match or beat it on eight of ten fixtures and lose on two, by 0.03% and 3.1%, entirely inside the compressed payload rather than the structure. Two things we do that it does not: remove near-duplicate frames, and tell you when re-encoding made your file bigger instead of handing the bigger file back.

These are two different jobs and picking the wrong one wastes quality you did not need to spend. Optimising removes redundancy: the file gets smaller and the animation is unchanged, so there is no reason not to do it. Compressing removes information: fewer pixels, fewer colours, fewer frames per second, until a file size you name is reached. Start here. If the result is still too big, the compressor takes over from where this leaves off.

A short decision list

• Start with the optimizer, always. It costs nothing visually and it is often enough on its own. There is no sense throwing away colours before removing pixels that were being stored twice.
• Use the compressor when a number is the requirement. "Under 8 MB for Discord", "under 256 KB for a custom emoji". It searches resolution, palette and frame rate together until it hits the number.
• Use the resizer when the dimensions are wrong. This tool will never change them. If the animation is 1920 wide and the column is 700, that is a resize, and doing it first makes everything else cheaper.
• Come back here afterwards. Optimising the output of a resize or a compress usually finds more, because those tools rebuild the frames and this one is what removes the repetition from them.

GIF Compressor · GIF Resizer

The default settings are chosen to be the ones nobody has to think about: frame differencing on, duplicates removed only when byte-identical, both lossy sliders at zero, dithering off. That combination cannot change what anyone sees, which is why it is the default — an optimizer that quietly altered the picture would be a compressor with a misleading name. Everything below is about when to move away from it.

By material

• Screen recordings and UI demos. The best case there is. The background is static, so the differences are tiny, and pauses in the recording produce byte-identical frames that cost nothing to remove. Defaults, and expect several times.
• Video-derived footage. Nothing is ever byte-identical because of the compression noise underneath, so switch duplicate removal to near-identical at 98% and move the difference tolerance up. Both are aimed at exactly this material.
• Stickers and logos on a transparent background. Frame differencing is unavailable — the format only has one see-through index and the background is using it — but frames are still cropped to their opaque content, which is usually worth more here than differencing would have been.
• Photographic and heavily dithered GIFs. There may be nothing to remove, and the tool will say so rather than hand you a larger file. Reduce the colour count, or use the compressor.

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. Animated or single-frame, interlaced or not, with a global palette or a different local palette on every frame. Sub-rectangle frames at an offset are composited onto the full canvas before anything is compared.
• Animated WebP and APNG in. Both are read by our own demuxers on every browser rather than by a native decoder, so frames and timing are identical everywhere. Both carry far more than 256 colours, so a palette is derived for them and the result is not colour-exact.
• GIF out, always. A standard GIF89a with one global colour table, per-frame delays, sub-rectangle frames, disposal methods and a Netscape loop extension.
• 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

GIF is decoded natively where the browser has a decoder for it 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. Animated WebP and APNG always take our own reader, which is what keeps frame counts and timing identical across engines. What a file claims by its name is ignored: the first sixteen bytes decide, so a `.gif` that is really something else is refused at intake rather than three minutes later.

Size and batch limits

• Free. One file up to 50 MB and up to 300 frames. Every structural lever is included — frame differencing, duplicate removal, transparency preservation, cropped frames — because those are what the tool is, and a free plan without them would be a demonstration rather than a tool. The colour table is capped at 128 entries.
• Pro. Up to 50 files at once, downloaded as one ZIP, no file-size or frame limit beyond what your device can hold, and the full 256-colour table that makes a colour-exact pass possible on any GIF.
• No dimension cap on either plan. The optimizer never changes dimensions, so a ceiling on them would be a limit on nothing. Both plans return the animation at exactly the size it arrived.
• The limit both plans share. 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 the progress ring keeps turning.

Nothing is uploaded. The file is decoded frame by frame on your machine, scanned once for repeats, transparency and colour count, mapped to a single shared palette, differenced against a running model of what a decoder would be showing, and written out as a standard GIF89a. All of it runs in a background thread so the page keeps painting throughout, and the palette mapping — the per-pixel part, and the expensive one — runs on your graphics hardware where it is available.

Why the same file optimises identically every time

• A deterministic quantiser. Median cut, not the randomised neural quantiser most GIF libraries use — and, where the source's colours fit, no quantiser at all. The same input with the same settings always produces byte-identical output.
• Identical results on every path. The graphics-accelerated and processor paths are required to produce the same bytes, not merely similar ones. Verified by running all three and comparing hashes: a path that chose a different palette entry would show as colour flicker between frames, which is far more visible in an animation than one wrong pixel is in a still.
• Checked against implementations that share no code. The rendered animation is read back by libvips, the frame structure by gifsicle, and the file's blocks by a reader written for the test pack. A file our own code both writes and reads proves nothing.
• Optimising twice changes nothing. Running the tool over its own output returns the same file and reports it as already optimised, which is the property that says the first pass finished the job.

Palette mapping is hardware accelerated where your device supports it, and the accelerated and fallback paths are verified to produce byte-identical output. Frame structure is checked against gifsicle and the rendered animation against libvips, neither of which shares any code with this tool. Measured on the reference device: 100 frames at 480x270 optimised in 252 ms, 4.07x smaller, with a mean colour error of 0.000 of 255. It all runs on your device, not our servers.

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