The ICO file format is an image file format for computer icons in Microsoft Windows. An ICO file holds one or more images at multiple sizes and color depths, from which Windows selects and scales the most appropriate one for a given use. A Windows application's own icon — shown on the desktop, in the Start menu, or in File Explorer — is stored in the same format inside its executable as an icon resource, rather than as a separate file.
The CUR file format is an almost identical format for non-animated cursors in Microsoft Windows. The two differ only in the bytes that identify the file and in a hotspot recorded in the CUR header — the pixel offset, in x,y coordinates, from the top-left corner of the cursor image to the point at which the user is actually pointing.
The ANI file format is used for animated Windows cursors. ANI is a RIFF container; each frame within it is a complete CUR-format image and may itself contain images at multiple sizes.
First introduced as monochrome images in Windows 1.0, the format acquired its directory-based multi-image structure in Windows 3.0 and support for larger sizes and higher color depths in Windows 95; Windows Vista added 256×256 images and PNG compression. Each image is stored either as a DIB or as a complete PNG file, and a file typically bundles several so the best match for the requested size and color depth can be chosen.
History Icons introduced in Windows 1.0 were monochrome; in Windows 1.x and 2.x, ICO and CUR files were raw binary images with no directory wrapper — each file contained a single such image, at 64×64 pixels for icons and 32×32 for cursors. The 64×64 icon size was designed for a 1024×1024 target display and was shown downscaled on the lower-resolution monitors of the era. These single-image icons and cursors were created with the SDK's Icon Editor (), which worked in separate Icon, Cursor and Bitmap modes. In icon and cursor modes it offered four pen "colors" — White, Black, Screen and — where a Screen pixel took on the color of the screen pixel already beneath it and a pixel took the opposite (inverted) color, the same transparent-and-invert behavior later carried by the 1-bit AND/XOR mask of the ICONDIR format (see below). The two masks were stored in the opposite order used by that later format, however: the AND mask came first, followed by the XOR mask, and each mask's rows were padded to a 2-byte (word) boundary rather than the 4-byte boundary the ICONDIR format uses. Cursors additionally stored a hotspot, which the Icon Editor placed at the image's center by default if the author did not set one explicitly. Applications loaded icons and cursors only from the resources compiled into an executable module, via the and functions, each taking a module handle and a resource name.
The multi-image ICONDIR format and the DIB-based frame layout were introduced in Windows 3.0, replacing the raw binary format: each file now begins with a directory of fixed-size entries followed by the image data as DIBs, using the 40-byte as the norm. The legacy 12-byte is also accepted; it is the bitmap header of OS/2 Presentation Manager 1.x, whose own icon and pointer resources were likewise built around an AND/XOR-mask-plus-image scheme comparable to the one Windows uses, though held in a different, multi-image-capable container. Shipping 3.x icons used only 1 bpp (monochrome) and 4 bpp (16-color VGA), often pairing both depths in a single file, with 8 bpp not yet in common use.
With Windows 95, the icon directory gained the headroom to describe images of any size from 1×1 up to 256×256 pixels (including non-square sizes) — by letting a or value of 0 stand for 256 pixels — and added a new 32 bpp color depth (16.7 million colors, without an alpha channel) on top of the 1, 4 and 8 bpp depths the format already supported; though these were format capabilities rather than depths the shell of the era actually rendered, and the shell could not display very large icons. Shipped system icons of the era remained 16-color (4 bpp) in practice. It was possible to enable 16-bit (65535 color) icons by setting the Shell Icon BPP value in the registry; the high-color icons feature of Microsoft Plus! for Windows 95 applied this setting. The Shell Icon Size registry value set the size of the large (desktop) shell icons and could be adjusted from 16 to 72 pixels through the Appearance tab of the Display Properties dialog, defaulting to 32 pixels; the small shell icon size was fixed and could not be changed. The notification area of the Windows taskbar was limited to 4 bpp icons until Windows Me when it was updated to support 16-bit icons.
Windows NT 4.0 was the first release to ship system icons at 8 bits per pixel (256 colors) and to add a 48×48-pixel size alongside the existing 16×16 and 32×32. The 256-color depth and the 48×48 size became common across the 98, Me and 2000 generation.
Windows XP extended the 32-bit format with an 8-bit alpha channel (24-bit color plus per-pixel transparency) and was the first release to ship system icons that used it, allowing semitransparent areas like shadows, anti-aliasing, and glass-like effects to be drawn in an icon. Its shell used 48×48-pixel icons in Windows Explorer, the largest size Microsoft recommended for the release; larger images were downscaled when no closer size was available.
The format could describe a 256×256 image well before Vista, but an uncompressed 32-bit image at that size needs about a quarter of a megabyte per frame (256 × 256 × 4 bytes), which made shipping such icons impractical. Windows Vista made 256×256 icons practical by adding support for storing frames in the compressed PNG format, and was the first release to render and ship system icons at that size. Although compression is not required, Microsoft recommends that all 32-bit color 256×256 icons in ICO files should be stored in PNG format to reduce the overall size of the file. The Windows Vista Explorer supports smoothly scaling icons to non-standard sizes which are rendered on the fly even if an image is not present for that size in the icon file. The Windows Vista shell adds a slider for "zooming" the icon sizes in and out. With users using higher resolutions and high DPI modes, larger icon formats (such as 256×256) are recommended. Windows Vista and later versions also dropped the ability to display icons stored in 16-bit (New Executable) modules.
The color depth of cursors trailed that of icons. On the 16-bit Windows 3.x line, cursors stayed monochrome (1 bpp) even after icons had moved to 16 colors (4 bpp) in Windows 3.0. Color cursors first appeared on the NT 3.x line, which shipped 4 bpp cursors, and reached the consumer line with Windows 95. 32-bit cursors did not appear until Windows Vista. Cursors that invert the screen pixels beneath them still include a monochrome (1 bpp) frame, since that is the only way to produce the effect (described below).
The pixel size of cursors stayed fixed at 32×32 on standard-DPI systems throughout the 9x and NT eras, up to Windows Vista. Through Windows XP, the desktop was not scaled continuously with DPI. On systems Windows XP treated as high-DPI — those whose primary display was 150 DPI or greater — XP doubled the nominal cursor size (/) to 64×64 so the pointer would not become too small to use, and Microsoft recommended authoring cursor sets with both 32×32 and 64×64 images for such systems — though the cursors XP itself shipped contained only 32×32. Windows Vista was the first release to scale icon sizes continuously with the display DPI. From Windows 7, the cursors shipped with Windows began carrying several sizes in a single file for the same reason — adding a 48×48 tier alongside the existing 32×32. Windows 8.1 added a 64×64 tier and introduced per-monitor DPI awareness, letting windows on different displays use different scale factors. From Windows 10 cursors also shipped in a larger five-size set. The system selects among these sizes by display scaling (see Default sizes and DPI scaling for the exact set).
Icon size and color-depth timeline The standard color depths and pixel sizes shipped in system icons changed over successive releases, as summarized below.
+ Standard shipped icon color depths and sizes by release Release Color depths (bpp) Standard sizes (px) Notes Windows 1.x–2.x 1 64 (icons), 32 (cursors) Raw single image, no directory Windows 3.x / NT 3.x 1, 4 32 ICONDIR + DIB introduced; 1 bpp + 4 bpp paired Windows 95 4 16, 32 Higher depths supported by the shell but rarely shipped; 16 px is the small (taskbar/notification-area) icon size Windows NT 4.0 / 98 / Me / 2000 4, 8 16, 32, 48 8 bpp and 48 px introduced in NT 4.0; became common by 98/Me Windows XP 4, 8, 32 16, 32, 48 32 bpp with alpha channel introduced Windows Vista / 7 4, 8, 32 16, 32, 48, 256 256 px added, stored as PNG Windows 8 / 8.1 4, 8, 32 16, 20, 24, 32, 40, 48, 64, 256 Eight-size ladder completed Windows 10 / 11 32 16, 20, 24, 32, 40, 48, 64, 256 Shipped icons are 32 bpp only
MIME type While the IANA-registered MIME type for ICO files is image/vnd.microsoft.icon, it was submitted to IANA in 2003 by a third party and is not recognized by Microsoft software, which uses image/x-icon or image/ico instead. See the second comment. Erroneous types image/ico, image/icon, text/ico and application/ico have also been seen in use.
Both ICO and CUR remain partially supported in current web browsers for legacy reasons, although the CUR format's screen pixel inversion feature was never implemented there.
Structure An ICO or CUR file is made up of an ICONDIR ("Icon directory") structure, containing an ICONDIRENTRY structure for each image in the file, followed by a contiguous block of all image data. Each image is stored either as a raw DIB (see DIB format) or as a complete PNG file (see PNG format). It is customary practice to store the image data in the same order as the entries in the image directory.
All values in ICO/CUR files are represented in little-endian byte order.
ICONDIR structure
Offset(bytes) Field Size(bytes) Description 0 idReserved 2 Reserved. Must be 0. 2 idType 2 Image type: 1 for ICO image, 2 for CUR image. Other values are invalid. 4 idCount 2 Number of images in the file. 6 idEntries idCount * 16 ICONDIRENTRY array. Each entry represents an image.
ICONDIRENTRY structure
Offset(bytes) Field Size(bytes) Description 0 bWidth 1 Image width in pixels. Can be any number between 0 and 255. 0 means width is 256. 1 bHeight 1 Image height in pixels. Can be any number between 0 and 255. 0 means height is 256. 2 bColorCount 1 Number of colors in the color table. For paletted depths: 2 for 1 bpp, 16 for 4 bpp; 0 for 8 bpp and above. An incorrect value affects image selection scoring for icons. 3 bReserved 1 Reserved. Must be 0. 4 wPlanes 2 In icon format: Specifies color planes. Should be 0 or 1.Setting the color planes to 0 or 1 is treated equivalently by the operating system, but if the color planes are set higher than 1, this value should be multiplied by the bits per pixel to determine the final color depth of the image. It is unknown if the various Windows operating system versions are resilient to different color plane values. In cursor format: Specifies the horizontal coordinates of the hotspot in number of pixels from the left. 6 wBitCount 2 In icon format: Specifies bits per pixel.The bits per pixel might be set to zero, but can be inferred from the other data; specifically, if the bitmap is not PNG compressed, then the bits per pixel can be calculated based on the length of the bitmap data relative to the size of the image. If the bitmap is PNG compressed, the bits per pixel are stored within the PNG data. It is unknown if the various Windows operating system versions contain logic to infer the bit depth for all possibilities if this value is set to zero.