A GIF file is a sequence of bytes that follow a strict layout. Open one in a hex editor and you see the signature, the screen header, colour tables, frames, and a trailer. Learn this layout and you will see what breaks when a GIF is corrupted, and what a repair tool can salvage. Work through the main blocks in order. Know which are required and which are optional, and you will know what a corrupted file might still contain.

The Signature and Version

Every GIF starts with a signature that is a few bytes long. It is either GIF87a or GIF89a. The difference between gif89a vs gif87a is that GIF89a added support for extensions, including the graphic control extension. Check this first. If the signature is missing or damaged, a repair tool cannot identify the file as a GIF. If the signature is intact, the file is at least recognizable as a GIF.

Logical Screen Descriptor

Right after the signature comes the logical screen header, which is a few bytes long. This block contains the canvas width, canvas height, packed flags, background colour index, and aspect ratio. The width and height are each a few bytes, little endian. The flags tell you whether a global colour table follows and how many colours it contains. This header is required. Without it, the image dimensions are unknown.

Colour Tables

Global And Local Palettes

A colour table holds at most 256 colours. Each colour entry is a few bytes: red, green, blue. The table can be global, used by all frames, or local to a single frame. Read the flags to get the table size: the number of colour entries is 2^(bits+1). If the global colour table is missing or truncated, colours may be wrong. The frame data can still be read if a local colour table is present.

Frames and Image Descriptors

Frame Layout And LZW Data

Each frame starts with an image header. It begins with byte 2C. It contains the left and top position of the frame on the canvas, the frame width and height, and another set of flags. After this header comes the LZW compressed pixel data. The data is stored in sub blocks of up to 255 bytes each. LZW compression is the core of how GIF stores pixel colours efficiently. If the image header is missing, the frame cannot be displayed. If the LZW data is corrupted, the frame may show visual artifacts or fail to decode.

Extensions (GIF89a Only)

GIF89a introduced extensions. The most common is the graphic control extension, which starts with bytes 21 F9. This extension sets frame delay, in hundredths of a second, and transparency options. Treat it as optional. If it is missing or damaged, the frame may still display, but the delay value may be treated as a default value.

The Trailer

The file ends with the trailer byte 3B. This byte is required. A missing trailer usually means truncation. In that case, keep the frames before the cut. A repair tool can often reconstruct a valid trailer to allow the file to open.

What Breaks and What Repair Can Keep

Salvage Rules By Block

When a GIF is corrupted, different blocks may be damaged. Work through this list to see what can be salvaged:

  • Signature damaged: The file cannot be identified as GIF. Repair may guess the version or try to fix the first few bytes.
  • Screen header damaged: Canvas size may be wrong. Repair may attempt to guess dimensions from the image headers.
  • Colour table missing or truncated: Colours may be wrong, but frame data can still be read if a local colour table exists.
  • Image header or LZW data damaged: That specific frame may be lost, but earlier frames can still be kept.
  • Trailer missing: Frames before the cut can usually be kept. Repair can add a trailer byte.

For example, if a file is truncated after the first frame, the second frame is lost. Save the first frame. If the LZW data in the middle of a frame is corrupted, that frame may not decode, but frames after it might still be readable if the image header is intact.