About

GIF89a remains the dominant format for short-loop animations across email clients, messaging platforms, and legacy web systems that reject modern video codecs. Producing a valid GIF requires LZW-compressed frame data, a global color table quantized to at most 256 entries, and precise graphic control extension headers that dictate per-frame delay in centisecond units (1 cs = 10 ms). An incorrectly constructed color table or missing Netscape application extension block will produce a static image or a single-play animation. This tool performs real binary GIF89a encoding in the browser using a complete LZW compressor, median-cut color quantization, and Floyd-Steinberg dithering. Limitations: maximum palette depth is 256 colors per frame. Photographic content with smooth gradients will exhibit banding artifacts inherent to the GIF specification.

Formulas

Each frame is quantized from true-color (24-bit RGB) to an indexed 256-color palette. The median-cut algorithm partitions the color space by recursively splitting the longest axis of the bounding box containing pixel colors. Floyd-Steinberg dithering distributes quantization error to neighboring pixels:

e = pixel_original − pixel_quantized

pixel(x+1, y) += e × 716
pixel(x−1, y+1) += e × 316
pixel(x, y+1) += e × 516
pixel(x+1, y+1) += e × 116

LZW compression builds a dictionary of pixel index sequences. The initial dictionary contains entries 0 through 2ⁿ−1 for the palette, plus a clear code (2ⁿ) and end-of-information code (2ⁿ+1). Code width starts at n+1 bits and grows as the dictionary expands, resetting at 4096 entries (12-bit maximum).

Where e = quantization error vector (RGB), n = color depth in bits (ceil(log₂(paletteSize))), minimum 2.

Reference Data

Parameter	GIF89a Spec Value	Notes
Max Colors	256	Global or local color table
Color Table Size	2¹ to 2⁸	Must be power of 2
Frame Delay Unit	10 ms (centisecond)	Minimum practical: 20 ms
Min Code Size (LZW)	2 to 8 bits	Derived from color depth
Max Image Width	65535 px	Spec limit; practical limit far lower
Max Image Height	65535 px	Memory-constrained in browsers
Loop Count	0 = infinite	Netscape 2.0 application extension
Disposal Method 0	No disposal	Frame accumulates
Disposal Method 1	Do not dispose	Leave frame in place
Disposal Method 2	Restore to background	Clear frame area
Transparency	1-bit alpha	Single transparent color index
LZW Initial Code Size	max(2, colorDepth)	Minimum is 2 bits
Sub-block Max Size	255 bytes	Data split into sub-blocks
Header Signature	GIF89a	6 ASCII bytes
Trailer Byte	0x3B	Marks end of file
Typical Web Delay	100 ms	10 fps equivalent
Smooth Animation	33 ms	30 fps equivalent
Cinematic Rate	42 ms	24 fps equivalent
Email-Safe Max Size	1 MB	Gmail/Outlook rendering limit
Social Media Max	5 - 15 MB	Platform-dependent

Frequently Asked Questions

The GIF specification limits each frame to a maximum of 256 indexed colors. Smooth gradients that span thousands of unique RGB values get quantized down to the nearest palette entry. Floyd-Steinberg dithering mitigates this by distributing the quantization error across neighboring pixels, producing a stippled pattern that approximates the original gradient. For photographic content with extensive gradients, consider using APNG or WebP animated formats instead.

A delay of 100 ms (10 fps) is standard for reaction GIFs and simple loops. For smoother motion, use 33 ms (≈30 fps), but expect file size to roughly triple because you need 3× more frames per second. Most email clients struggle with GIFs over 1 MB, so for email-bound content, stay at 10 fps with no more than 15-20 frames. The minimum reliable delay across browsers is 20 ms; values below that get clamped to ~100 ms by most renderers.

Loop control uses the Netscape 2.0 Application Extension block. A value of 0 means infinite loop. A value of 1 means the animation plays once and stops on the last frame. Some older viewers and social media platforms override this value and force infinite looping regardless. There is no cross-platform guarantee that a finite loop count will be respected.

This tool caps dimensions at 800×800 pixels. Each frame at 800×800 requires 2.56 MB of raw RGBA pixel data. With 50 frames, that is 128 MB of memory before encoding even begins. The LZW compression and palette quantization run in a Web Worker to avoid freezing the UI, but total encoding time scales with width × height × frameCount. For web use, 480×480 or smaller produces the best balance of quality and file size.

Yes. If your source images contain transparency (PNG with alpha channel), the encoder detects pixels below a transparency threshold and assigns them the transparent color index in the GIF palette. GIF only supports 1-bit transparency - a pixel is either fully opaque or fully transparent. Semi-transparent pixels get rounded to the nearest state. Anti-aliased edges against a transparent background may show fringing artifacts.

Source images in JPEG or PNG use fundamentally different compression algorithms (DCT-based lossy or DEFLATE-based lossless) that are more efficient for photographic data than LZW. GIF's LZW compression works best on flat-color graphics with horizontal runs of identical pixels. A photographic frame with noise or dithering produces poor LZW compression ratios. Reducing the output dimensions and frame count are the most effective ways to control file size.