← Back to ResearchRanked

GIF Optimizer

Frame differencing · colour merging · fully local

English 简体 繁體

Drop your GIFs here

or click to choose · multiple files · Ctrl+V works · release anywhere on the page

Several .gif files at a time, up to 60 MB each. Every file is decoded and re-encoded inside your own browser - nothing is uploaded.

Optimization settings

0

No GIFs yet - drop a few in and see

What this tool is

GIF Optimizer is a GIF compressor that runs in your own browser. The format itself is plain: every frame stores a full indexed picture, so even when only the cursor moved, the whole canvas gets encoded again - and plenty of exporters never even do frame differencing. This page decodes each frame, recomposes it (honouring the disposal methods), then compares it pixel by pixel against what the screen showed before: only the changed rectangle is written, every other pixel keeps a transparent index so the previous frame shows through.

On top of that there are three more levers: merging colours that are almost the same (the anti-aliasing greys in text and screenshots collapse into one, which makes LZW find far longer repeats), reducing the palette to 256/128/64/32/16 colours with optional Floyd-Steinberg dithering, and rescaling or decimating frames. Change anything and the whole queue recomputes, so you see the price in bytes and in quality side by side and stop at the preset you can live with. Transparency, per-frame delays and the loop count are written back as they were; comments and application extensions are dropped.

Features

How to use it

  1. Drop .gif files anywhere on the page, click Choose GIF files for multi-select, or paste an animated GIF from the clipboard.
  2. Start on Keep quality to see what frame differencing alone buys you. Not enough? Move to Recommended, then Aggressive, or switch to Custom and tune each lever.
  3. Click Compare on a row to play the original and the optimized version next to each other - size, dimensions and frame counts are printed in the header.
  4. Download a single result, or grab the whole batch as one ZIP. Output files are named original-name-opt.gif, with a counter appended if two would collide.

FAQ

How much smaller will it get?
Two cases. If the source never had frame differencing, the win is large: 30%-60% off is normal when the background is static and only a small area moves. If it came out of an optimizer already, Keep quality usually leaves 5%-20% - mostly the fresh LZW pass and the dropped metadata - and the real reductions come from colour reduction, colour merging, rescaling and frame decimation: colour merging alone typically adds another 15%-25% on screenshots, and 75% size with decimation can push the file under 30% of the original.
Is Keep quality really lossless?
Yes, as long as the colours that appear across all frames fit in 255 entries: the palette is built from the colours actually present in your file (a GIF frame holds at most 256 colours and one index is reserved for transparency), with no rescale, no decimation and no delay changes. When the union of the frames exceeds 255 - common when each frame carries its own palette - the palette has to be merged once before differencing can work, which changes a few pixels by amounts that are hard to see; those rows are marked "colours reduced". Comments and application extensions (metadata) are always dropped, deliberately.
Why did dithering make the file bigger?
Error diffusion shreds a flat area into checkerboard noise. It looks finer, but LZW can no longer reuse long repeats and differencing has to write more changed pixels - on the same gradient we measure 20%-50% more bytes with it on. That is why it defaults to off; turn it on only when banding genuinely bothers you.
Does decimation make the animation choppy or faster?
Not faster: when one frame in N is kept, the dropped frames' durations are folded into the kept one, so total playback length is unchanged. Visually, fast motion starts to skip, which is fine for chat avatars and preview clips but not for typing effects or mouse trails - leave decimation off for those.
Are my files uploaded? Do transparency and looping survive?
Nothing is uploaded: decoding, composing, quantizing, differencing and encoding all run in a worker thread on this page, and the app has no endpoint to send files to - it keeps working with the network off. Transparent pixels, per-frame delays and the NETSCAPE loop count are written back unchanged (a single-frame result simply stops carrying the loop block).

Other tools on this site

Runs entirely in your browser · no upload · free · English / 简体 / 繁體