Skip to main content
Tracemute Clean a file

← All formats

GIF

The animated web format from 1989. Less metadata than JPEG, but Adobe stuffed XMP into it anyway.

Extensions
.gif
MIME
image/gif
Strip
Lossless
Updated
2026-05-27

GIF is the format your reaction images live in, the format Slack and Discord render natively, the format Adobe Photoshop still exports to. Designed in 1989 with a tight binary layout, it predates EXIF and was deliberately metadata-light — until Adobe added an XMP extension and editors started writing identifying comments into it.

What it carries

GIF’s binary layout is a sequence of blocks after a 13-byte header:

  • Comment Extension (0x21 0xFE) — free-form text. Photoshop writes Photoshop CC 2024 here; some cameras write copyright strings; vintage GIFs often carry the editor name and creation date.
  • Application Extension (0x21 0xFF) — vendor-tagged blocks with an 11-byte identifier:
    • NETSCAPE2.0 — animation loop count (the reason animated GIFs loop forever). Kept.
    • XMP DataXMP — Adobe’s XMP packet, with the same dc:creator / dc:rights / xmp:CreatorTool fields you’d find in a JPEG.
    • MagickIamI (ImageMagick), Adobe ICC profile blocks, and other vendor extensions — all dropped unless explicitly on the keep list.
  • Plain Text Extension (0x21 0x01) — rare in the wild; kept as harmless.
  • Graphic Control Extension (0x21 0xF9) — per-frame timing, transparency, and disposal method. Required for animation. Kept.

What’s unique

GIF’s animation control lives in two distinct places — the per-frame Graphic Control Extension (timing, transparency) and the NETSCAPE2.0 Application Extension (loop count). Strip either and the animation breaks: no loop, or no timing. Tracemute’s allow-list keeps both.

The XMP-in-GIF convention is Adobe’s own; the GIF spec says nothing about it. Naive strippers miss it because they only look for tEXt-style chunks; the XMP packet hides inside an Application Extension with the magic identifier XMP DataXMP plus a 257-byte trailer.

What Tracemute does

The handler is a native block walker with an allow-list:

  1. Walk every block from after the Logical Screen Descriptor + Global Color Table to the trailer (0x3B).
  2. Keep Image Descriptors (image data) and their Local Color Tables byte-identical.
  3. Keep Graphic Control Extensions and the NETSCAPE2.0 / ANIMEXTS1.0 animation-loop blocks.
  4. Drop Comment Extensions and every Application Extension that isn’t on the keep list — XMP packets, ImageMagick blocks, vendor signatures all go.
  5. Concatenate the kept blocks into a fresh GIF byte stream.

The LZW-coded image data inside each Image Descriptor is copied verbatim. No re-encoding, no palette quantisation.

What survives

The Global Color Table (palette), every Image Descriptor + Local Color Table, all Graphic Control Extensions, and the animation loop. Animation survives intact. The image-data bytes are byte-identical to the input.

Where this format shows up

Real situations that hand you a GIF file.