About

GIF89a supports a maximum of 256 colors per frame via indexed color tables. Naive tools often apply a single global palette, producing visible banding and dithering artifacts across frames with different dominant hues. This encoder builds a per-frame local color table using Median Cut quantization, splitting the RGB cube along the axis of greatest variance to preserve perceptual fidelity. The result approaches true color appearance within the GIF specification constraint of 2⁸ entries per table. All binary construction - LZW compression, sub-block packaging, NETSCAPE2.0 loop extension - runs entirely in your browser via a Web Worker. No server upload occurs. Note: GIF is inherently lossy for photographic content exceeding 256 unique colors per frame. For such cases, consider WebP or APNG formats.

Formulas

Each frame's pixel data is quantized from 24-bit RGB to an indexed palette via Median Cut. The color distance metric used:

d = √(r₁ − r₂)² + (g₁ − g₂)² + (b₁ − b₂)²

Where r, g, b are the red, green, and blue channel values (0 - 255). Median Cut recursively partitions the color space into k ≤ 256 buckets by splitting along the channel with the largest range. Each bucket's centroid becomes a palette entry.

LZW compression builds a code table starting with 2ⁿ + 2 entries (palette indices plus Clear Code and EOI Code). Variable-length codes grow from (n + 1) bits up to 12 bits, resetting the table when the code value reaches 4096.

minCodeSize = max(2, ceil(log₂(paletteSize)))

Frame delay in the Graphic Control Extension is stored as a 16-bit unsigned integer in hundredths of a second. A value of 5 = 50 ms = 20 fps.

Reference Data

Parameter	GIF89a Spec Value	Notes
Max Colors per Frame	256	Local color table limit
Color Table Sizes	2, 4, 8 … 256	Must be powers of 2
LZW Minimum Code Size	2 - 8 bits	Derived from color table bit depth
Max LZW Code Size	12 bits	Code table max 4096 entries
Sub-block Max Size	255 bytes	Data split into sub-blocks
Frame Delay Resolution	10 ms	Hundredths of a second
Min Practical Delay	20 ms	Browsers clamp < 20 ms to ~100 ms
Loop Count Range	0 - 65535	0 = infinite loop
Max Dimensions	65535 × 65535 px	Practical limit: memory
Transparency	1-bit alpha	Fully transparent or fully opaque
Disposal Method 0	No disposal	Leave frame in place
Disposal Method 1	Do not dispose	Draw over previous frame
Disposal Method 2	Restore to background	Clear to canvas background
Disposal Method 3	Restore to previous	Revert to prior state
Interlacing	4-pass Adam7 variant	Rows: 0,8,4,2,1 spacing
File Signature	GIF89a	6-byte ASCII header
Typical Web FPS	10 - 30 fps	Higher = larger file

Frequently Asked Questions

The GIF89a specification limits each frame to 256 indexed colors. This encoder uses Median Cut quantization to select the optimal 256 colors per frame, preserving the most perceptually important hues. Photographic images with thousands of unique colors will show some quantization. For lossless animation of photographic content, use APNG or WebP.

Most browsers clamp GIF frame delays below 20 ms (2 hundredths of a second) to approximately 100 ms. Setting a delay of 10 ms will not produce 100 fps playback - it will typically render at ~10 fps. The practical minimum for consistent cross-browser behavior is 20 ms (50 fps).

LZW codes start at (minCodeSize + 1) bits and grow as new patterns are added. When the code value reaches 4096 (the 12-bit ceiling), a Clear Code is emitted and the table resets to its initial state. This prevents unbounded memory growth and is required by the GIF specification.

This encoder does not currently implement transparency. GIF supports 1-bit alpha (a single palette index marked as transparent), but applying it requires identifying which pixels should be transparent - typically via a chroma key or alpha channel. All pixels are treated as fully opaque.

GIF file size is driven by three factors: canvas dimensions, number of frames, and color complexity. LZW compresses runs of identical palette indices efficiently, so images with large flat-color areas compress well. Photographic content with high spatial frequency (noise, gradients) compresses poorly. Reducing dimensions or frame count is the most effective way to reduce file size.

There is no hard limit in the GIF specification. The practical limit is browser memory. Each frame at 500×500 pixels consumes approximately 1 MB of raw pixel data. For a 100-frame animation, expect ~100 MB of working memory during encoding. The Web Worker will report progress so you can monitor the process.