A GIF file is a strictly ordered binary stream. It opens with a 6-byte header (GIF89a or GIF87a), then a Logical Screen Descriptor encoding canvas size and color table config in a single packed byte. The Global Color Table follows — a flat array of RGB triplets acting as the image palette. Every pixel is stored as an index into this table, not as a color. The file ends with a single 0x3B trailer byte.
The file skeleton: header, screen descriptor, global color table, app extensions (like NETSCAPE2.0 for looping), comments, and trailer. Click to inspect decoded fields.
GIF is palettized — up to 256 RGB colors in a lookup table. Each compressed pixel is a byte index into this palette, which is why gradients band. Hover for RGB values.
LZW compression is the engine inside every GIF. It reads pixel indices sequentially, building a dictionary of repeating patterns on the fly. Both encoder and decoder build identical dictionaries independently — nothing extra is stored. Codes are packed into a variable-width bitstream starting at minCodeSize + 1 bits, growing up to 12. When the dictionary fills (4096 entries), a CLEAR code resets it. The bitstream is chunked into sub-blocks of ≤255 bytes, each prefixed by its length.
Animation is simply multiple frames in sequence. Each is preceded by a Graphic Control Extension specifying delay (in centiseconds), a disposal method (0: unspecified, 1: leave, 2: clear to bg, 3: restore previous), and optional transparency. Looping uses a NETSCAPE2.0 application extension — not part of the GIF spec. Loop count 0 = infinite. Browsers clamp delays below ~20ms, capping practical speed at ~50fps.
Each frame consists of a GCE (timing + transparency), an Image Descriptor (position, size, palette flag), and Image Data (LZW-compressed indices in sub-blocks). Frames can be smaller than the canvas and positioned via offsets. Click a frame to preview it; click a block pill for details.