Graphics Interchange Format

LZW Compression

LZW (Lempel-Ziv-Welch) is a dictionary-based compression algorithm. The encoder starts with a table of 256 single-byte entries (one per possible color index). As it reads pixel data left-to-right, top-to-bottom, it builds longer dictionary entries from recurring sequences. When a sequence already exists in the table, it outputs that entry's code instead of the raw bytes. Repeated patterns — solid color runs, repeating tile backgrounds, uniform regions — compress extremely well. Photographic content with high pixel-to-pixel variation produces poor LZW ratios.

The algorithm is elegant but carries history. Unisys held a patent on LZW (U.S. Patent 4,558,302) and began enforcing licensing fees in 1994. The controversy directly motivated the creation of PNG as a patent-free alternative. The Unisys patent expired in the United States in June 2003 and worldwide by 2004. LZW is now freely usable.

Color Table Architecture

GIF files contain a Global Color Table (GCT) defined in the header — up to 256 RGB entries shared across all frames. Individual frames can optionally include a Local Color Table (LCT) that overrides the GCT for that frame only. Each table stores between 2 and 256 colors, with the size encoded as a power of two.

The 256-color-per-frame limit is absolute. Photographic images must be quantized down from millions of colors using dithering algorithms (Floyd-Steinberg, ordered, etc.), which introduces visible dot patterns. This is why GIF is fundamentally unsuitable for photographs.

However, the local color table trick expands total palette range in animations. Each frame can define its own 256-color palette. A 30-frame animation could theoretically use 7,680 distinct colors across all frames. Some tools exploit this by splitting a single static image into tiled sub-frames with different local palettes — a hack that produces better color fidelity at the cost of larger files and viewer compatibility issues.

Animation Internals

GIF animation works by stacking multiple image frames inside a single file. The Graphic Control Extension block precedes each frame and defines three properties:

Frame delay is specified in centiseconds (hundredths of a second). A value of 10 means 100 ms between frames. Values below 2 are treated inconsistently — most browsers clamp delays of 0 or 1 to 100 ms, making ultra-fast frame rates impossible to achieve reliably.

Disposal method controls what happens to the canvas before the next frame renders:

Wrong disposal methods cause ghosting, flashing, or accumulated artifacts. Disposal method 2 with transparency is the standard approach for animations where each frame differs significantly.

Transparency index designates one palette entry as fully transparent. This is strictly 1-bit: a pixel is either 100% opaque or 100% transparent. There is no partial transparency, no alpha gradients, no anti-aliased edges against unknown backgrounds. PNG's 8-bit alpha channel (256 levels of transparency) is the standard solution when smooth edges matter.

File Size Problem

Animated GIFs are enormous relative to their visual content. Each frame is stored as a separate compressed image. There is no inter-frame compression — no motion vectors, no temporal prediction, no reference frames. A 3-second 480p GIF is typically 2-5 MB; the same clip as MP4 H.264 is 150-300 KB — 10-20x smaller. At 720p the gap widens further, because GIF's per-frame LZW compression scales with pixel count while video codecs exploit temporal redundancy.

Frame optimization tools reduce size by storing only the rectangular region that changed between frames (delta frames) rather than full canvas replacements. Tools like Gifsicle apply this optimization and can cut 20-40% off naive GIF exports. Even so, the format remains orders of magnitude less efficient than modern video codecs for motion content.

Interlacing

GIF supports a 4-pass interlacing scheme. Rather than storing rows sequentially (0, 1, 2, 3...), an interlaced GIF stores rows in this order: pass 1 (every 8th row starting at 0), pass 2 (every 8th row starting at 4), pass 3 (every 4th row starting at 2), pass 4 (every 2nd row starting at 1). The viewer can display a rough image after receiving only 12.5% of the data. This mattered on dial-up connections. On modern broadband it adds a few bytes of overhead with no practical benefit for most use cases.

Platform Behavior

Major platforms silently convert uploaded GIF files to video. Twitter transcodes GIFs to MP4. Telegram converts them to MPEG4 video stored as "GIF" in the UI. Discord re-encodes large GIFs. Imgur converts uploads to MP4 served via <video> tags while keeping .gifv URLs. The visual experience is identical but bandwidth drops by 90% or more. When these platforms display "GIFs," they are almost always playing muted, looping video files.

GIF87a vs GIF89a

GIF87a supports only static images and animation via multi-image packing (without explicit timing control). GIF89a added four extension blocks: Graphic Control Extension (frame delay, disposal, transparency), Comment Extension (embedded text metadata), Plain Text Extension (overlaid text rendering — almost never used), and Application Extension (application-specific data, most notably the Netscape looping extension that enables infinite animation loops). The Netscape 2.0 Application Extension block is not part of the GIF89a specification itself — it is a de facto standard that every browser honors.

Modern Alternatives

For short looping clips, inline <video> with MP4 or WebM is the correct technical choice. APNG replaces GIF for animated graphics that need lossless quality and full alpha. GIF persists because of ecosystem inertia — messaging apps, Slack integrations, Giphy APIs, and email clients where <video> tags are blocked.

Gotchas

Dithering on photographic frames creates noisy, grainy results that compress poorly and look worse than a lossy JPEG at a fraction of the size. GIF has no audio track — it is an image format, not a multimedia container. Maximum frame rate is capped at roughly 50 fps in theory (2 centisecond delay), but browser clamping makes anything above 20 fps unreliable. Large animated GIFs (10 MB+) cause memory pressure on mobile browsers because every frame must be decoded into an uncompressed bitmap — a 100-frame 720p GIF consumes over 250 MB of RAM when fully decoded.