Animated GIF Compressor
Compress an animated GIF locally by scaling dimensions, reducing colors, or dropping frames while verifying duration and loop behavior.{{ summaryTitle }}
{{ summaryLine }}
- Dimensions
- {{ sourceMetaValues.width }} × {{ sourceMetaValues.height }} → {{ outputMeta.width }} × {{ outputMeta.height }}
- Frames
- {{ sourceMetaValues.frames }} → {{ outputMeta.frames }}
- Duration
- {{ formatDuration(sourceMetaValues.duration_ms) }} preserved
- Loop
- {{ loopLabel(outputMeta.repeat) }} preserved
The chart renderer is unavailable. The exact source and output bytes remain in the compression ledger.
| Signal | Source | Processed | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.source }} | {{ row.output }} |
An animated GIF stores a timed sequence of palette-based images. Its size depends on canvas dimensions, frame count, color complexity, transparency, and how efficiently repeated visual information is encoded. Because those factors interact, the smallest acceptable result usually comes from changing one or two clear levers and then watching the animation again.
Reducing width and height cuts the number of pixels in every frame. Limiting colors makes each kept frame simpler, but gradients can develop bands. Keeping every second frame can reduce image data sharply, though motion becomes less smooth. Dithering trades clean color blocks for a patterned mix that can make gradients look smoother while sometimes increasing visual noise or bytes.
- Dimensions usually provide the most predictable reduction because both axes scale together.
- Palette size balances color fidelity against a smaller set of colors.
- Frame retention changes motion detail while preserving total playback duration.
- Palette mapping changes how source colors are represented, not the canvas size or timing.
A GIF can become larger after re-encoding, especially when the source was already well optimized. A requested size should therefore be treated as a warning threshold, not a promise. If the result misses a publishing limit, change the settings and run a new reviewed pass rather than assuming the encoder can reach any target safely.
Playback is part of correctness. A useful compressed animation must still have the intended dimensions, frame sequence, total duration, loop behavior, transparency, and visible quality. Byte savings alone cannot establish that.
How to Use This Tool:
Begin with moderate settings, review motion and color, then make a stronger pass only if the output is still too large.
- Choose one animated GIF. Still images are rejected, and the source must fit the displayed file, dimension, frame, duration, and decoded-pixel limits.
- Select Dimensions and Color quality. A 75% scale with 128 colors is a useful first pass for many animations.
- Choose Keep every frame for smoother motion or Keep every second frame for stronger reduction. The skipped delay is carried into the kept sequence so total duration stays unchanged.
- Use Nearest color for flat artwork and crisp edges. Try Ordered dither when gradients band visibly.
- Set Optional size warning only when a real upload or publishing cap exists, then compress and compare the original and processed previews.
- Download the result only after the reported dimensions, frames, duration, loop behavior, and byte count match your needs.
Interpreting Results:
Use the side-by-side animation as the quality check and the byte comparison as the delivery check. The output is acceptable only when motion, gradients, edges, transparency, and small text still work at the intended display size.
- A positive size reduction means the processed file is smaller; it does not grade visual quality.
- An Above threshold warning means the final byte count exceeded the optional limit. It does not trigger another lossy pass.
- A result larger than the original should usually be discarded unless the changed visual characteristics are worth the extra bytes.
- Preserved duration and loop behavior confirm timing structure, but browsers can still impose their own minimum frame delays during playback.
When motion becomes jerky, restore every frame before sacrificing more colors. When gradients posterize, raise the palette or try ordered dithering before restoring full dimensions.
Technical Details:
GIF animation is reconstructed as full RGBA frames before resizing and palette reduction. This matters because many GIFs store small frame patches plus disposal instructions rather than a complete canvas for every moment. Each kept full frame is resized, optionally dithered, quantized to its own bounded palette, and encoded back into the animation.
Formula Core
Dimension scaling uses one ratio for both axes and rounds to the nearest whole pixel. Frame retention keeps every sth frame.
W and H are pixel dimensions, F is frame count, and s is 1 for every frame or 2 for every second frame. The optional target converts from entered KB to bytes by multiplying by 1,024; it does not enter the encoding formula.
Transformation Core
| Stage | Transformation | Preserved or changed |
|---|---|---|
| Frame reconstruction | Apply frame patches and disposal behavior to a full canvas. | Preserves the displayed source sequence before compression. |
| Frame retention | Keep every frame or every second frame; merge grouped delays. | Total duration stays equal while motion detail may fall. |
| Resize | Scale both dimensions by 25%, 50%, 75%, or 100%. | Aspect ratio is preserved subject to whole-pixel rounding. |
| Palette mapping | Quantize each kept frame to 32, 64, 128, or 256 colors, with optional ordered dithering. | Color detail may change; transparent pixels remain one-bit transparent. |
| Verification | Decode the result and compare dimensions, frame count, summed delays, and loop setting. | A mismatch blocks the output. |
GIF delay values are stored in hundredths of a second. When every second frame is removed, the delays from each pair are summed and assigned to the retained frame. This preserves the total measured duration but cannot preserve every intermediate pose.
Rule Core
| Boundary | Accepted range |
|---|---|
| Source file | Valid GIF87a or GIF89a, 13 bytes through 12 MB |
| Dimensions | 1 through 1,600 pixels per side |
| Animation | 2 through 240 image frames |
| Total measured duration | 0 through 60,000 ms |
| Decoded frame area | At most 60 million width × height × frame pixels |
The encoder uses a separate palette for every kept frame. A smaller palette often reduces color detail, but final byte count also depends on spatial repetition and compressed index patterns, so palette size alone cannot predict savings.
Privacy Notes:
The GIF is decoded, transformed, verified, and prepared for download in the browser. The source animation is not uploaded for processing. An internet connection may be needed to load the compression capability before processing begins.
Worked Examples:
Stronger reduction with preserved duration
A 320 × 180 animation with four frames and a 1,200 ms duration is set to 50% dimensions, 64 colors, every second frame, and ordered dithering. The plan produces a 160 × 90 canvas with two frames while retaining the 1,200 ms total duration. The frame count and pixels fall, but playback must still be reviewed because two intermediate poses have been removed.
References:
- Graphics Interchange Format Version 89a, CompuServe, July 31, 1990.
- How to create an animated GIF with ImageMagick, Simplified Guide.