GIF Compressor

GIF Compressor takes the file apart and builds a new one. The GIF is parsed in JavaScript — the LZW streams are decoded, each frame's own palette is read, and the disposal method is honoured so partial frames composite the way a viewer would draw them. Every kept frame is then redrawn on a canvas at the size you asked for and handed to gif.js, which picks a fresh 256-colour palette per frame and encodes the result in Web Workers. Your GIF is never sent anywhere and no copy of it is kept. What does cross the network is the tool's own code — the processor module, gif.js and its worker script, all served from this site and all fetched on first use, then reused from memory.

There is no quality slider in GIF the way there is in JPEG, because the format has no such dial: size comes from pixel area, multiplied by frame count, plus the cost of the palettes. So the controls are those three levers directly. Frames keeps every frame, or every 2nd, 3rd or 4th. Scale runs from 25% to 100% in 5% steps, and matters most, since bytes fall roughly with the square of it. Colours sets how densely the encoder samples pixels when it builds each palette — sampling every pixel gives the truest colour and the largest file, sparse sampling gives a rougher one and a smaller file. Dropped frames hand their delay to the frame kept before them, so a clip that ran for four seconds still runs for four seconds; it simply steps more coarsely. The original's loop setting survives too: a GIF with no loop block still plays once, and one set to loop forever still does.

The second mode aims at a number instead. Give it a maximum in KB or MB and it re-encodes repeatedly, changing one lever at a time in order of least visible damage: the palette sampling first, then the scale, then — only if you leave the frame-dropping box ticked — the frame rate. Each candidate is really encoded and its bytes counted, so the size reported is the size of the file you get. Two behaviours protect you from a pointless result. A GIF already under the budget is handed straight back untouched, because re-encoding it would probably make it bigger. And if the search stops with every attempt larger than the source, the original is returned unchanged with a note saying so, rather than a quarter-size animation that somehow weighs more.

It is worth knowing in advance where this stops. Re-encoding a GIF that was already well optimised often gains nothing, and when that happens the result says plainly that it is not smaller than the original. Dithering is switched off, which keeps the file down but leaves visible banding in gradients and soft shading. Every pass composites, scales and quantises every frame, which is slow — a 36-frame 480×360 animation takes tens of seconds for a single pass — so the size search is rationed: five further attempts after the first on a small GIF, only two on a large one, and a large one opens at 60% scale with the coarsest palette instead of working down from full size. That ration is also why the search can give up while settings it never tried remain. Decoding refuses a file outright past 2,000 frames or 300 million total frame pixels. The output is always a GIF: nothing here trims the clip, reorders it, or writes a modern format, and any comment block in the source is dropped.

Runs on your device. Your file is processed directly in this browser.