GIF metadata is thin by design. The format has no EXIF, no IPTC and no GPS fields, so a GIF never says which camera or phone made it or where. What a GIF can carry is metadata of a simpler kind: text comments, an XMP packet, an ICC profile and animation settings, all stored as extension blocks between the frames.
Blocks in the GIF file format
A GIF starts with GIF87a or GIF89a, a logical screen descriptor and an optional global color table. After that it is a sequence of blocks: image descriptors (0x2C), extensions (0x21 followed by a label byte), and a trailer (0x3B) at the end. Extension data is split into sub-blocks of at most 255 bytes, each preceded by its length, with a zero byte closing the list.
The extension types were defined in GIF89a. These are the labels that matter:
| Label | Extension | What it carries |
|---|---|---|
0xF9 | Graphic Control | Frame delay, transparent color, disposal |
0xFE | Comment | Free text |
0xFF | Application | Loop count, XMP, ICC, C2PA, vendor data |
0x01 | Plain Text | Text drawn over the image, rarely supported |
Application extensions start with an 8-byte identifier and a 3-byte authentication code. NETSCAPE2.0 holds the loop count, XMP DataXMP the XMP packet, ICCRGBG1012 an ICC profile. The C2PA specification adds C2PA_GIF, placed after the header and before the first image descriptor.
What ExifTool finds in an animated GIF
A three-frame GIF made with ImageMagick, then given a creator and a license with ExifTool:
$ exiftool -v1 loop.gif | sed -n '/^Application Extension: NETSCAPE/,/^Image:/p'
Application Extension: NETSCAPE/2.0
+ [BinaryData directory, 3 bytes]
| AnimationIterations = 0
Graphic Control: delay=0.50
Application Extension: ImageMag/ick
GIF_Extensions_ImageMag/ick = gamma=0.454545
Comment = made with convert
Application Extension: XMP Data/XMP
+ [XMP directory, 2951 bytes]
| XMPToolkit = Image::ExifTool 12.76
| Creator = Jane Doe
| Rights = CC BY 4.0
Image: left=0 top=0 width=64 height=64The NETSCAPE2.0 data is 01 00 00: sub-block ID 1, then a 16-bit loop count where 0 means loop forever (ExifTool prints it as Infinite in normal output). ImageMagick also leaves its own application extension with a gamma value. The comment was added by ImageMagick when the file was created.
XMP is the odd one. It is not split into sub-blocks; the packet is written raw, followed by a 258-byte "magic trailer" of 0x01, then 0xFF counting down to 0x00, then the block terminator. A decoder that does not know XMP reads the text as sub-block lengths, and whichever byte it lands on, the trailer walks it down to the terminator so it can skip the block safely.
What converters keep
GIFs made from video with ffmpeg carry only the NETSCAPE2.0 loop block. ImageMagick converting a geotagged iPhone JPEG to GIF dropped the GPS, the EXIF and the XMP, and quantized the image to 256 colors, but two things made it across: the JPEG's comment segment became a GIF comment, and the Display P3 ICC profile was embedded as an ICCRGBG1012 extension. A comment written years ago by some editing tool can travel this way without anyone noticing.
Editing and removing GIF metadata
Our tools do not accept GIF files; the metadata remover takes JPEG, TIFF, PNG and WebP. ExifTool writes the three things GIF supports, a comment, XMP and an ICC profile:
exiftool -Comment="Jane Doe" -XMP-dc:Creator="Jane Doe" -XMP-dc:Rights="CC BY 4.0" loop.gif
exiftool -all= loop.gifUse -Comment, not -GIF:Comment, which ExifTool rejects as not writable. The -all= strip on the file above removed the XMP and the comment and kept the NETSCAPE2.0 block, so the animation still loops. The ImageMagick extension stayed too.
Converting a GIF to JPEG only makes sense for a single still frame: JPEG has no animation and no transparency, and the only gain is EXIF support. For animations, PNG (APNG) or WebP keep the motion and offer real metadata containers; see the PNG page.