ICO / CUR Inspector

Because the width and height in a directory entry are single bytes, and 256 does not fit in a byte. The format solves this by defining 0 to mean 256, so a 256 × 256 member is written with both size bytes set to zero. A reader that takes the byte at face value reports 0 × 0 — or worse, treats the member as empty and skips it. This page applies the rule, which is why the entry-bytes column shows 0, 0 next to a declared size of 256 × 256. It is also the reason no icon can hold a member larger than 256 pixels: there is nowhere in the entry to say so.

Structurally almost nothing: the same header, the same directory, the same payloads. Two things differ. The type word in the header is 1 for an icon and 2 for a cursor, and the two 16-bit fields that an icon uses for colour planes and bits per pixel hold the hotspot x and y in a cursor — the point inside the picture that actually does the clicking. That means reading a cursor as an icon gives you a bit depth of, say, 3, which is meaningless. The extension is unreliable in both directions, so this page reads the type word and switches the column between depth and hotspot accordingly, and it says so when the name and the header disagree.

Because a BMP member is really two bitmaps stacked in one: the colour image, called the XOR bitmap, and below it a 1-bit AND mask that says which pixels let the screen show through. The BITMAPINFOHEADER describes both at once, so its height field counts both. The real height is half of it. The mask is easy to get wrong twice over: its rows are padded to four bytes independently of the colour rows, so a 24-pixel-wide mask has 4-byte rows, not 3, and it is packed one bit per pixel with a set bit meaning transparent. This page shows the mask offset and stride so you can check that arithmetic against your own reader.

Both are legal and one file can mix them, which Vista-era icons routinely do. The rule of thumb is that 256 × 256 should be PNG — a 256 bitmap with a mask costs about 256 KB per member and PNG compresses it to a fraction — and the small sizes are usually kept as BMP for compatibility, because the Windows XP shell shows nothing at all where a PNG member should be. Modern browsers read both without complaint. Since nothing in the directory records which one a payload is, a reader has to look at the first eight bytes of each payload for the PNG signature; that is exactly what the payload column here is showing.

That member is invisible in anything that honours alpha, and perfectly fine in anything that uses the AND mask instead. The two mechanisms coexist: a 32-bit BMP member has an alpha byte per pixel and also carries a 1-bit mask, because the format requires the mask whether or not it is needed. Exporters that write the mask correctly but leave alpha at zero produce icons that look right in the Windows shell and vanish in a browser tab. The reverse case — real alpha and an all-zero mask — is the normal modern shape, and the tool marks the mask as redundant there.

It means one of them is lying and the result depends on who reads the file. Windows sizes the member from the directory entry, so a 32 × 32 PNG stored under an entry that declares 48 × 48 gets stretched, softly and permanently. Some readers instead trust the payload and quietly render a different size than the one they promised. The mismatch usually comes from an editor that resized the picture and rewrote the payload without touching the directory, and it is invisible unless something reads both — which is why this page compares the IHDR and the BITMAPINFOHEADER against the entry that points at each of them.