The absolute smallest valid transparent GIF comes in at 33 bytes.
data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEAAAAALAAAAAABAAEAAAIA
47 49 46 38 39 61 01 00 01 00 00 00 00 21 F9 04
01 00 00 00 00 2C 00 00 00 00 01 00 01 00 00 02 00
This used to be 32 bytes, but it turns out that an extra 0x00 byte is required for Safari on MacOS, due to it strictly requiring a Block Terminator in the LZW data.
Explanation
Achieving the smallest possible GIF depends on the implementation of the GIF spec being used. Web browsers have often been lenient when it comes to decoding GIF files. At one point, 14 bytes was enough to render a transparent GIF in Chrome, but it no longer works. You may find one GIF that works as transparent in one browser but white/black in another. For example, a different 22-byte GIF still works in Chrome, but is now opaque white in modern Firefox. And then it might not even open in software like Gimp, Paint and Photoshop. So generally, it is best to follow the standards and not rely on hacky solutions (although, there's very little practical use for spacer GIFs beyond 2020!).
Following the spec, I found that the smallest near-valid transparent GIF is 32 bytes. “Near-valid”, because the trailer and some of the LZW data can be discarded, and it will still open in practically all software. In more stricter terms, 33 bytes are required to render in Safari as of writing, and a strictly valid GIF would be 37 bytes, which adds 3 extra bytes for LZW data sub-blocks and 1 byte for the trailer.
This is done by following the GIF spec, and each component can be broken down as follows:
- File signature/version, 6 bytes
- Logical Screen Descriptor, 7 bytes
- Optional: Global Color Table, 6 bytes1
- Optional: Graphics Control Extension, 8 bytes2
- Image Descriptor, 10 bytes
- LZW Sub-Block Image Data, 1-4 bytes3
- Optional: Trailer (
0x3B), 1 byte?
1 The Global Color Table can be removed safely by disabling it in the Logical Screen Descriptor
2 This is required for transparency in most software
3 Only 2 or 3 bytes of the LZW data are required and the bytes can be almost anything. Though only the first byte of 0x02 is strictly required. A terminating byte of 0x00 may be required in some cases (Safari).
? Trailer can be removed without ill effects.
Most GIF software require a Global/Local Color Table to be present. Further reductions (e.g. deleting Global Color Table) may work in some browsers, but their effects are usually implementation-specific. Edit: There is a flag to disable the Global Color Table, and it doesn't seem to cause any problems.
Other Examples:
Valid examples must open in all applications that support GIF (Paint, Photoshop, Gimp) as well as browsers.
The following 33 bytes is opaque white in all cases (3 extra LZW bytes):
47 49 46 38 37 61 01 00 01 00 80 01 00 FF FF FF 00
00 00 2C 00 00 00 00 01 00 01 00 00 02 02 44 01
data:image/gif;base64,R0lGODdhAQABAIABAP///wAAACwAAAAAAQABAAACAkQB
The following 30 bytes should be opaque white in all cases, but is transparent in Chrome(?likely a bug in Chrome?):
47 49 46 38 37 61 01 00 01 00 80 01 00 FF FF FF 00
00 00 2C 00 00 00 00 01 00 01 00 00 02
data:image/gif;base64,R0lGODdhAQABAIABAP///wAAACwAAAAAAQABAAAC
The following 24 bytes render as a transparent GIF in Chrome, white in Firefox, and black in Photoshop/Paint/Gimp (valid GIF, but lacks color information--unpredictable):
47 49 46 38 39 61 01 00 01 00 00 00 00 2C 00 00 00 00 01 00 01 00 00 02
data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAAC
