About

A binary-color GIF contains exactly two entries in its Global Color Table, yielding a 1-bit index per pixel. This constraint produces the smallest possible GIF files and forces deliberate design decisions. The GIF89a specification (CompuServe, 1989) mandates LZW compression on the index stream with a minimum code size of 2 for palettes of 2 - 4 colors. Miscalculating sub-block boundaries or clear-code insertion frequency produces files that render correctly in some decoders but corrupt in others. This tool encodes every byte of the GIF binary in-browser: header, logical screen descriptor, Netscape looping extension, graphic control extensions with configurable delay, and properly terminated LZW sub-blocks. No server round-trip occurs.

The pixel grid maps each cell to palette index 0 or 1. Frame dimensions are fixed across the animation per the GIF spec (the Logical Screen Descriptor locks w and h globally). Approximation note: this tool targets small pixel-art dimensions (up to 64 × 64). Larger canvases are technically valid but impractical for hand-painting. Frame delay granularity is 10 ms per the spec, though most browsers clamp values below 20 ms to approximately 100 ms.

Formulas

The GIF Global Color Table size is determined by a 3-bit field N in the packed byte. The actual number of entries is:

entries = 2^{(N + 1)}

For a binary palette, N = 0, giving 2¹ = 2 entries (6 bytes total). The LZW clear code and EOI code derive from the minimum code size m:

clearCode = 2^m , eoiCode = 2^m + 1

For binary images, m = 2 (GIF minimum is 2 even for 1-bit palettes), so clearCode = 4 and eoiCode = 5. First available code for new table entries is 6. The code width starts at m + 1 = 3 bits and grows as the table fills, up to a maximum of 12 bits (4096 entries).

Frame delay in the Graphic Control Extension is stored as a 16-bit unsigned integer in units of 10 ms:

delay_actual = value × 10 ms

Where value is the stored integer. A stored value of 10 yields 100 ms (10 fps). Total file size for an uncompressed single-frame binary GIF is approximately:

size ≈ 6 + 7 + 6 + 19 + 8 + 10 + 1 + lzwBytes + 1 + 1 bytes

Where lzwBytes depends on pixel data compressibility. For w × h pixels with high redundancy (solid color), LZW achieves significant compression.

Reference Data

GIF Block	Offset	Size (bytes)	Purpose
Header	0	6	Signature & version (`GIF89a`)
Logical Screen Descriptor	6	7	Canvas w, h, color table flags, background index
Global Color Table	13	6	2 colors × 3 bytes (RGB)
Netscape Extension	19	19	Loop count (0 = infinite)
Graphic Control Ext.	per frame	8	Delay time, disposal method, transparency
Image Descriptor	per frame	10	Frame position & size, local color table flag
LZW Min Code Size	per frame	1	Minimum code size (always 2 for binary palette)
Image Data Sub-blocks	per frame	variable	LZW-compressed pixel indices, max 255 bytes/block
Block Terminator	per frame	1	0x00 ends image data
Trailer	end	1	0x3B terminates file
LZW Clear Code	stream	-	Value = 2^minCodeSize = 4
LZW EOI Code	stream	-	Value = clear code + 1 = 5
Max Code Size	-	-	12 bits (max table size 4096)
Color Table Size Flag	byte 10	3 bits	0 = 2 colors, 1 = 4, etc.
Packed Byte (LSD)	byte 10	1	GCT flag, color resolution, sort, GCT size
Disposal Method 1	GCE	-	Do not dispose (overlay frames)
Disposal Method 2	GCE	-	Restore to background
Sub-block Max	-	255	Maximum bytes per LZW data sub-block
Browser Min Delay	-	-	Browsers clamp < 20 ms to ~100 ms

Frequently Asked Questions

The GIF specification mandates a minimum code size of 2, even when the palette contains only 2 entries (which would require only 1 bit per index). This is because a code size of 1 would make the initial code width 2 bits with only codes 0 (data), 1 (data), 2 (clear), 3 (EOI) - leaving no room for table growth before the first width increase. The spec avoids this edge case by requiring m ≥ 2.

Most browsers (Chrome, Firefox, Safari) clamp GIF frame delays below 20 ms (stored value 2) to approximately 100 ms. A delay of 0 is especially problematic - some decoders interpret it as "as fast as possible" while others default to 100 ms. For consistent cross-browser behavior, use delays of 30 ms or above.

When the code table reaches 4096 entries (code width = 12 bits), a clear code must be emitted to reset the table. The encoder outputs code 4 (the clear code for m = 2), resets the table to initial entries 0 - 5, and resets code width to 3 bits. Failure to reset produces corrupt output in strict decoders.

Yes. The Graphic Control Extension supports a transparency index. You designate one of your two palette entries as transparent. However, this tool focuses on opaque binary art. To achieve transparency, you would set the GCE transparency flag and assign index 0 or 1 as the transparent index - effectively making your GIF a 1-visible-color animation.

This tool caps dimensions at 64 × 64 pixels. At that size, you have 4096 cells to paint per frame. Larger grids are technically valid GIF (up to 65535 × 65535), but hand-painting becomes impractical. For larger images, import or algorithmic generation would be more appropriate.

Yes. Disposal method 1 (do not dispose) overlays each frame atop the previous, creating cumulative drawing effects. Method 2 (restore to background) clears the canvas to the background color before each frame, producing clean independent frames. For most animations, method 2 is correct. This tool uses method 2 by default to ensure each frame renders independently.