ICO and CUR: Containers Where the Hotspot Is the Whole Point

An .ico file is not an image and a .cur file is not a picture of a pointer. Both are directories: a small table at the front of the file listing several images at different sizes and colour depths, followed by the image data itself. Windows picks whichever entry suits the display scale and the context it needs the artwork for.

The two formats are nearly the same file. One field at offset 2 in the header holds 1 for an icon and 2 for a cursor, and that single value is the entire difference in identity. Mislabelling one as the other is common enough that a careful reader checks the field rather than trusting the extension.

The hotspot#

The second difference is the interesting one. In an icon, each directory entry carries two 16-bit fields describing colour planes and bit depth. In a cursor, those same two fields hold the hotspot: the exact pixel inside the image that counts as the click point. A crosshair clicks at its centre, an arrow at its tip, a text cursor at the middle of its bar.

Nothing else in common computing carries that idea. A PNG has no field for it, a JPEG has no field for it, and no raster format you might convert to has anywhere to put it. This is the honest limit of the conversion and it deserves to be said before anything else.

Two kinds of frame inside one container#

Each entry in the directory points at image data stored one of two ways. The legacy form is a headerless device-independent bitmap at 1, 4, 8, 24 or 32 bits per pixel, followed by a separate one-bit AND mask that says which pixels are transparent. Since Windows Vista, an entry may instead hold a complete PNG, which is how a 256-pixel icon stays a sensible size.

Both are read here. Convert ICO to PNG and convert CUR to PNG prefer an embedded PNG frame when one exists and fall back to decoding the legacy bitmap with its palette and mask when it does not. The mask is applied, so a converted icon has real transparency rather than a coloured background pretending to be empty.

One quirk worth knowing: the width and height in a directory entry are single bytes, so 256 is written as zero. A reader that takes the value literally decides a 256-pixel icon is zero pixels wide and either crashes or silently skips it. If a tool tells you an icon is empty, this is usually why.

Which image you get#

Because the output is a single image and the input is a pile of them, something has to choose. The largest usable frame wins: the biggest embedded PNG if any are present, otherwise the biggest supported bitmap frame. That is almost always what someone extracting artwork wants, and it is worth knowing rather than guessing.

• The other sizes are not exported. They remain in the source file, untouched, but they are not in the result.
• The 16-pixel version, which is frequently a separately drawn simplification rather than a scaled copy, is the one you are most likely to miss.
• Colour depth below the chosen frame is not merged in. There is no compositing across entries.
• A cursor with several sizes loses the size table along with the hotspot, for the same reason: both belong to the container.

Building one rather than opening one#

Convert PNG to ICO wraps your image as a single-entry icon with a PNG frame inside, which is the modern form and what browsers ask for. Note the word single: one image goes in and one entry comes out, and the ceiling is 256 pixels in each direction because the format has no way to describe a larger one. If you want an icon that holds several hand-tuned sizes, build each size and assemble them, which is the process set out in making a favicon that looks right at 16 pixels.

Going sideways is possible too. Convert CUR to ICO gives you the artwork in the icon container, which is useful for documentation and asset libraries, and drops the hotspot in the process for the reason described above. The ICO format reference and the CUR format reference list what each container can hold.