gizmobench

GIF Compressor

Most GIF compressors take your file up to a server and hand back a link, so you wait in a queue and your animation sits on a stranger's disk. This one decodes the GIF in this browser tab, composites every frame, and writes a new file here, so a 5 MB GIF never leaves the machine. It also separates the three levers that actually change the size, instead of hiding them behind one quality slider: the width, the number of colours each frame's palette may hold, and how many frames are kept. The before and after sizes beside the panes are measured on the two real files, never estimated, and dropping frames hands each dropped frame's delay to the frame before it, so the animation keeps the length it started with. When the new file comes out larger than the one you opened, which happens with a GIF that was already well optimised, the tool prints both numbers and says so rather than calling it compression.

Originalnothing open

Drop a GIF here, or choose one below.

0 bytesno timeline yet
Compressednothing yet

Every frame is decoded and written again in this tab.

0 bytesno timeline yet

· or drop one anywhere on the stage

Never uploadedNo accountUp to 20 MBUp to 300 frames
Width
Colors
Keep every
Area

No GIF open yet. Choose one, or drop it on the stage.

  • Sizemeasured on both files, not estimated
    Open a GIF to measure it.
  • Durationframe delays rebalanced
    Open a GIF to read its timeline.
  • Framesevery frame kept
    Open a GIF to count them.

Three levers, shown separately because they do different things: the width scales every frame, the palette limits how many colours a frame may use, and the frame step drops frames and hands their time to the frame before them. The ceiling is 20 MB, 300 frames and 80 million decoded pixels, because every frame is unpacked to full size in the memory of this tab while it works. The panes show the first frame of each file; the GIF you download animates.

Decoded and written here, frame by frame. Decoded and re-encoded in your browser, so the file never leaves this machine. The sizes shown are measured on the result, not estimated, and the animation keeps the total duration it started with. A GIF that is already small can come out larger, and the tool says so rather than calling it compression.

Common questions

What do the three controls actually change?
Width scales every frame, and the height follows the original shape so nothing is stretched: halving the width takes roughly three quarters of the pixels out of the file. Colors is the size of the palette each output frame is allowed, 256, 128 or 64, and each frame gets its own palette chosen from its own pixels, so cutting it to 64 costs the most in photographic gradients and very little in flat colour or line art. Keep every drops frames: every 2nd or every 3rd, which takes out half or two thirds of the image data. They are shown separately because they damage different things, and the measured size beside the result pane tells you what each one bought.
Why did my GIF come out larger instead of smaller?
Two reasons, and the tool reports both with the real numbers rather than hiding them. The first is that you asked for no reduction: full width, 256 colours and every frame means the file is only rewritten, and a rewrite can land anywhere. The second is how GIF stores animation. Many GIFs only store the rectangle that changed in each frame, while this tool composites every frame, writes it out whole and clears the canvas between frames, which is what makes cropping, resizing and frame thinning correct. A GIF that was already optimised that way can grow when it is rebuilt. When that happens the result pane and the Size row both say larger, with both sizes, and the original is the file worth keeping.
Is my GIF uploaded anywhere?
No. The file is read by a JavaScript GIF decoder running in this tab, redrawn on a canvas here, and written back out by a JavaScript GIF encoder here. There is no upload, no queue, no account and no request of any kind: no byte of the animation reaches a server, an analytics call or an error report. The only thing kept between visits is the palette size and frame step you chose, stored in this browser, and the platform's Start over button clears that.
What are the size limits, and why does a local tool have any?
20 MB, 300 frames and 80 million decoded pixels, which is the width times the height times the frame count. They exist because decoding a GIF expands it: every frame becomes a full canvas of red, green, blue and alpha bytes in memory, so an 80 million pixel decode is already more than 300 MB of working memory before anything is encoded. Past that a phone stops responding rather than finishing. Nothing is uploaded either way, so the ceiling is this machine's memory rather than a server's patience, and a file over any of the three is refused with the number it reached instead of a frozen tab.
Does dropping frames make the animation shorter or faster?
No. Each dropped frame's delay is added to the kept frame before it, so the total playing time is unchanged: a 2.13 second animation at 64 frames is still 2.13 seconds at 32. The Duration row prints the before and after so you can check it. Two details make that exact. A GIF stores delays in hundredths of a second, so the rebalanced delays are snapped to whole hundredths with the rounding carried forward rather than dropped. And a frame that asks for a delay of 0 or one hundredth of a second is played at 100 milliseconds by every current browser, so the tool counts what will really play instead of the number in the file.
Can I crop a GIF here as well as resize it?
Yes. Set Area to Crop and four fields appear: left, top, width and height, in the picture's own pixels. The rectangle is read against the full canvas, never against an individual frame, which matters because GIF frames are often smaller than the canvas and offset inside it. Every frame is composited first and then the same rectangle is taken from each one, so the crop cannot drift from frame to frame, and the animation keeps its timeline. A rectangle that runs past the edge is pulled back to the edge, and one with no area is refused with the reason.
Why does the result look banded at 64 colours?
Because a smaller palette has fewer colours to spend on a gradient, and this encoder maps each pixel to the nearest palette entry without dithering. That is the right trade for the animation most people are compressing, screen captures, cartoons, flat colour and text, where 64 colours are nearly indistinguishable from 256 and the file is much smaller. A photographic or heavily shaded GIF bands instead, and 128 or 256 colours with a smaller width usually looks better than 64 colours at full size. Both files are in front of you, so compare the first frames before you download.

Decoded and re-encoded in your browser, so the file never leaves this machine. The sizes shown are measured on the result, not estimated, and the animation keeps the total duration it started with. A GIF that is already small can come out larger, and the tool says so rather than calling it compression.