smallest filesize for transparent single pixel image

Question

I\'m looking for the smallest (in terms of filesize) transparent 1 pixel image.

Currently I have a gif of 49 bytes which seems to be the most popular.

But I

Answer 1

Transparent dot, 43 bytes:

echo "\x47\x49\x46\x38\x39\x61\x1\x0\x1\x0\x80\x0\x0\xff\xff\xff\xff\xff";
echo "\xff\x21\xf9\x04\x1\x0a\x0\x1\x0\x2c\x0\x0\x0\x0\x1\x0\x1\x0";
echo "\x0\x2\x2\x4c\x1\x0\x3b";

Orange dot, 35 bytes:

echo "\x47\x49\x46\x38\x37\x61\x1\x0\x1\x0\x80\x0\x0\xfc\x6a\x6c\x0";
echo "\x0\x0\x2c\x0\x0\x0\x0\x1\x0\x1\x0\x0\x2\x2\x44\x1\x0\x3b";

Without color table (possibly painted as black), 26 bytes:

echo "\x47\x49\x46\x38\x39\x61\x1\x0\x1\x0\x0\xFF";
echo "\x0\x2C\x0\x0\x0\x0\x1\x0\x1\x0\x0\x2\x0\x3B";

The first two I found some time ago (in the times of timthumb vulnerability) and I don't remember the sources. The latest one I found here.

P.S.: Use for tracking purposes, not as spacers.

Answer 2

I think this is most memorable 1x1 (38 bytes):

data:image/gif,GIF89a%01%00%01%00///;

According to GIF header spec:

GIF Header

Offset   Length   Contents
  0      3 bytes  "GIF"
  3      3 bytes  "87a" or "89a"
  6      2 bytes  <Logical Screen Width>
  8      2 bytes  <Logical Screen Height>

First %01%00 is width = 0x0001

note that 1px is %01%00 equals to 0x0001

not %00%01 otherwise it will be 0x0100

Second is height, same as above

next 3 bytes you can input anything, browser can parse it

e.g. /// or !!! or ,,, or ;;; or +++

last one byte must be: ; , !

by the way, if you use /// or \\\ at the 3 bytes next to size

page title will display last character, otherwise will show gif,...

tested with Chrome, Firefox both worked, IE does not works

Answer 3

You shouldn't really use "spacer gifs". They were used in the 90s; now they are very outdated and they have no purpose whatsoever, and they cause several accessibility and compatibility problems.

Use CSS.

Answer 4

Here is a valid 33 byte transparent GIF that (should) work everywhere

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 are usually lenient when it comes to decoding GIF files. You may find a really small GIF that works as transparent in one browser but white/black in another. And it might not even open in software like Gimp, Paint and Photoshop.

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.

This is done by following the GIF spec, and each component can be broken down as follows:

1. File signature/version, 6 bytes
2. Logical Screen Descriptor, 7 bytes
3. Optional: Global Color Table, 6 bytes¹
4. Optional: Graphics Control Extension, 8 bytes²
5. Image Descriptor, 10 bytes
6. LZW Data, 1-4 bytes³
7. Optional: Trailer (0x3B), 1 byte⁴

¹ The Global Color Table can be removed safely by disabling it in the Logical Screen Descriptor
² This is required for transparency in most software
³ 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 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 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 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

Answer 5

http://polpo.org/blank.gif is a 37 byte transparent GIF made with gifsicle.

In css-ready base64 format:

data:image/gif;base64,R0lGODlhAQABAHAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw==

Answer 6

Here is what I use in a C# byte array (avoids file access)

static readonly byte[] TrackingGif = { 0x47, 0x49, 0x46, 0x38, 0x39, 0x61, 0x1, 0x0, 0x1, 0x0, 0x80, 0x0, 0x0, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x2c, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x1, 0x0, 0x0, 0x2, 0x2, 0x44, 0x1, 0x0, 0x3b };

In asp.net MVC this can be returned like this

return File(TrackingGif, "image/gif");