Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to ICO (file format).
Nothing was collected or created yet.
ICO (file format)
View on Wikipediafrom Wikipedia
| ICO | |
|---|---|
| Filename extension | .ico |
| Internet media type | image/x-icon[1] (but see below) |
| Uniform Type Identifier (UTI) | com.microsoft.ico |
| Developed by | Microsoft |
| Type of format | Graphics file format for computer icons |
| Container for | BMP and PNG |
| Extended to | CUR |
| CUR | |
|---|---|
| Filename extension | .cur |
| Internet media type | image/vnd.microsoft.icon |
| Uniform Type Identifier (UTI) | com.microsoft.cur |
| Developed by | Microsoft |
| Type of format | Graphics file format for mouse cursors |
| Container for | BMP |
| Extended from | ICO |
The ICO file format is an image file format for computer icons in Microsoft Windows. ICO files contain one or more small images at multiple sizes and color depths, such that they may be scaled appropriately. In Windows, all executables that display an icon to the user, on the desktop, in the Start Menu, or in file Explorer, must carry the icon in ICO format.
The CUR file format is an almost identical image file format for non-animated cursors in Microsoft Windows. The only differences between these two file formats are the bytes used to identify them and the addition of a hotspot in the CUR format header; the hotspot is defined as the pixel offset (in x,y coordinates) from the top-left corner of the cursor image to where the user is actually pointing the mouse.[citation needed]
The ANI file format is used for animated Windows cursors.
History
[edit]Icons introduced in Windows 1.0 were 32×32 pixels in size and were monochrome.[2] Support for 16 colors was introduced in Windows 3.0.[citation needed]
Win32 introduced support for storing icon images of up to 16.7 million colors (TrueColor) and up to 256×256 pixels in dimensions.[3] Windows 95 also introduced a new Device Independent Bitmap (DIB) engine.[4] However, 256 color was the default icon color depth in Windows 95. It was possible to enable 65535 color (Highcolor) icons by either modifying the Shell Icon BPP value in the registry[3][5] or by purchasing Microsoft Plus! for Windows 95. The Shell Icon Size value allows using larger icons in place of 32×32 icons and the Shell Small Icon Size value allows using custom sizes in place of 16×16 icons.[3] Thus, a single icon file could store images of any size from 1×1 pixel up to 256×256 pixels (including non-square sizes) with 2 (rarely used), 16, 256, 65535, or 16.7 million colors; but the shell could not display very large sized icons. The notification area of the Windows taskbar was limited to 16 color icons by default until Windows Me when it was updated to support high color icons.
Windows XP added support for 32-bit color (16.7 million colors plus 8-bit alpha channel transparency) icon images, thus allowing semitransparent areas like shadows, anti-aliasing, and glass-like effects to be drawn in an icon. Windows XP, by default, employs 48×48 pixel icons in Windows Explorer. Windows XP can be forced to use icons as large as 256×256 by modifying the Shell icon size value but this would cause all 32×32 icons throughout the shell to be upscaled.[3] Microsoft only recommended icon sizes up to 48×48 pixels for Windows XP.[6] Windows XP can downscale larger icons if no closer image size is available.[3]
Windows Vista added full support for 256×256-pixel 32-bit color icons,[Notes 1] as well as support for the compressed PNG format. 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.[7][8]
The SM_CXCURSOR and SM_CYCURSOR[9] system metric in Windows reports the nominal size of the cursor, typically 32 pixels on classic systems. This metric does not reflect the maximum or actual size of all cursors used in the system. Windows commonly loads 32×32 cursors by default but also supports other sizes such as 48×48 or 64×64 pixels depending on display scaling and resolution. The metric serves as a guideline value for resource design and alignment rather than a strict constraint. Actual cursor sizes can vary, especially in modern high-DPI environments. The metric originates from legacy design decisions and remains primarily for compatibility with older applications.[10]
MIME type
[edit]While the IANA-registered MIME type for ICO files is image/vnd.microsoft.icon,[11] it was submitted to IANA in 2003 by a third party and is not recognised by Microsoft software, which uses image/x-icon or image/ico instead.[12][13] Erroneous types image/ico, image/icon, text/ico and application/ico have also been seen in use.[11]
File structure
[edit]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 bitmap data (which may be in either Windows BMP format, excluding the BITMAPFILEHEADER structure, or in PNG format, stored in its entirety).[3]
Images with less than 32 bits of color depth follow a particular format: the image is encoded as a single image consisting of a color mask (the "XOR mask") together with an opacity mask (the "AND mask").[6][3] The XOR mask must precede the AND mask inside the bitmap data; if the image is stored in bottom-up order (which it most likely is), the XOR mask would be drawn below the AND mask. The AND mask is 1 bit per pixel, regardless of the color depth specified by the BMP header, and specifies which pixels are fully transparent(1) and which are fully opaque(0). The XOR mask conforms to the bit depth specified in the BMP header and specifies the numerical color or palette value for each pixel. Together, the AND mask and XOR mask make for a non-transparent image representing an image with 1-bit transparency; they also allow for inversion of the background. The height for the image in the ICONDIRENTRY structure of the ICO/CUR file takes on that of the intended image dimensions (after the masks are composited), whereas the height in the BMP header takes on that of the two mask images combined (before they are composited). Therefore, the masks must each be of the same dimensions, and the height specified in the BMP header must be exactly twice the height specified in the ICONDIRENTRY structure.[14]
32-bit images (including 32-bit BITMAPINFOHEADER-format BMP images[Notes 2]) are specifically a 24-bit image with the addition of an 8-bit channel for alpha compositing. Thus, in 32-bit images, the AND mask is not required, but recommended for consideration. Windows XP and higher will use a 32-bit image in less than True color mode by constructing an AND mask based on the alpha channel (if one does not reside with the image already) if no 24-bit version of the image is supplied in the ICO/CUR file. However, earlier versions of Windows interpret all pixels with 100% opacity unless an AND mask is supplied with the image. Supplying a custom AND mask will also allow for tweaking and hinting by the icon author. Even if the AND mask is not supplied, if the image is in Windows BMP format, the BMP header must still specify a doubled height.
It's important to note that in the AND mask, as for the pixel array of the bitmap, padding bytes must be appended to the end of each row in order to bring up its length to a multiple of four bytes since it's basically a (monochrome) bitmap.[3] The AND mask of an 8x8 pixels bitmap would have 1 byte of data and 3 bytes of padding(8*8*1bpp = 64 bits/8 = 8 bytes of total rows, so each row is 1 byte and 3 bytes of padding are needed), a 16x16 bitmap's AND mask would have 2 bytes of data and 2 bytes of padding, a 32x32 bitmap's AND mask would have 4 bytes of data and no padding. Note that the quantity of padding bytes needed depend on the dimensions of the bitmap and not its color depth since the AND mask is 1 bit per pixel regardless.
All values in ICO/CUR files are represented in little-endian byte order.
ICONDIR structure
[edit]| 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
[edit]| 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.[Notes 1] |
| 1 | bHeight | 1 | Image height in pixels. Can be any number between 0 and 255. 0 means height is 256.[Notes 1] |
| 2 | bColorCount | 1 | Number of colors in the color palette. Should be 0 if the image does not use a color palette. |
| 3 | bReserved | 1 | Reserved. Must be 0. |
| 4 | wPlanes | 2 | |
| 6 | wBitCount | 2 | |
| 8 | dwBytesInRes | 4 | Image data size in bytes. |
| 12 | dwImageOffset | 4 | Specifies the offset of BMP or PNG data from the beginning of the ICO/CUR file. |
Referenced image data
[edit]All image data referenced by entries in the image directory proceed directly after the image directory. It is customary practice to store them in the same order as defined in the image directory.
BMP format
[edit]If an image is stored in BMP format, it must exclude the opening BITMAPFILEHEADER structure.
The height of the BMP image must be twice the height declared in the image directory. This is because the actual image data will contain two parts: the actual image immediately followed by a 1 bit mask of the same size as the image used to determine which pixels will be drawn.
The mask has to align to a DWORD (32 bits) and should be packed with 0s. A 0 pixel means 'the corresponding pixel in the image will be drawn' and a 1 means 'ignore this pixel'. The pixel colour is either explicit for 24 and 32 bit versions (which do not have colour tables), indexed for the other depths (1,2,4,8,16) in table of a four byte (BGRA) colours that follows the BITMAPINFOHEADER.
For 1 bit, typically the two colours are #00000000 and #00FFFFFF and the A channel is ignored.
The pixel data for 1,2,4,8 and 16 bits is packed by byte and DWORD aligned.
24 bit images are stored as B G R triples but are not DWORD aligned.
32 bit images are stored as B G R A quads.
Originally, ICOs and CURs were intended to be used on monochrome displays and used the formula Output = (Existing AND Mask) XOR Image but on colour screens, the cursor is composed using A channel blending and the mask is used to determine which pixels are included or excluded.
PNG format
[edit]If an image is stored in PNG format, then there is no BITMAPINFOHEADER and the contents of the PNG image in full are used instead.
The ability to read PNG images from ICO format images was introduced in Windows Vista.[7] A PNG image can be stored in the image in the same way as done for a standard Windows BMP format image, with the exception that the PNG image must be stored in its entirety, with its file header in 32bpp ARGB format.[7]
Note: CUR files cannot use PNG image data and must use BMP image data as per ICOs.[7]
Icon and cursor resources
[edit]Icons and cursors in Portable Executable (EXE or DLL) files are organised in resources of type RT_GROUP_ICON, RT_GROUP_CURSOR, RT_ICON and RT_CURSOR.[15]
RT_GROUP_ICON and RT_GROUP_CURSOR resources contain one NEWHEADER structure and one or more RESDIR structures which have almost the same format as corresponding ICONDIR and ICONDIRENTRY structures in ICO/CUR files. Main difference is in RESDIR that the last member of the structure contains two-byte resource identifier of the RT_ICON/RT_CURSOR instead of image offset in the file.
NEWHEADER/RESDIR structures also referred as GRPICONDIR/GRPICONDIRENTRY in many sources.[16]
NEWHEADER structure
[edit]| Offset (bytes) |
Field | Size (bytes) |
Description[17] |
|---|---|---|---|
| 0 | Reserved | 2 | Reserved. Must be 0. |
| 2 | ResType | 2 | Resource type: 1 for icon, 2 for cursor. Other values are invalid. |
| 4 | ResCount | 2 | Number of RESDIR structures that immediately follow this structure. |
RESDIR structure
[edit]| Offset (bytes) |
Field | Size (bytes) |
Description[18] |
|---|---|---|---|
| 0 | Width | 1 (ICO) or 2 (CUR) | Image width in pixels. Can be any number between 0 and 255. 0 means width is 256.[Notes 1] |
| Varies | Height | 1 (ICO) or 2 (CUR) | Image height in pixels. Can be any number between 0 and 255. 0 means height is 256.[Notes 1] |
| 2 | ColorCount | 1 (ICO) or 0 (CUR) | Number of colors in the color palette. Should be 0 if the image does not use a color palette. |
| 3 | reserved | 1 (ICO) or 0 (CUR) | Reserved. Must be 0. |
| 4 | Planes | 2 | Color planes. Should be 0 or 1.[Notes 3] |
| 6 | BitCount | 2 | Bits per pixel.[Notes 5] |
| 8 | BytesInRes | 4 | Size of the resource in bytes. |
| 12 | IconCursorId | 2 | Unique ordinal identifier of the RT_ICON or RT_CURSOR resource. |
RT_ICON and RT_CURSOR resources have the same image data format as in ICO files and can store PNG images as well. Additionally, first four bytes of RT_CURSOR resource data contain the cursor hotspot data, as two WORD (16 bit) values (in contrast to CUR files, in which hotspot data is contained in the ICONDIRENTRY structure).[19]
Icon library
[edit]An icon library is a way to package Windows icons. It is typically a 16-bit New Executable or a 32-bit Portable Executable binary file having an .ICL extension with icon resources being the packaged icons. Windows Vista and later versions do not support viewing icons from 16-bit (New Executable) files.[20]
See also
[edit]Notes
[edit]- ^ a b c d e Since Windows 95 size of an image in the ICONDIRENTRY structure might be set to zero, which means 256 pixels. Since Windows Vista, the size of an image is determined from the BITMAPINFOHEADER structure or PNG image data which technically allows storing icons with larger than 256 pixels, but such larger sizes are not recommended by Microsoft.
- ^ The classic BITMAPINFOHEADER bitmap format supports storing images with 32 bits per pixel. When saved as a standalone .BMP file, "the high byte in each [pixel] is not used". However, when this same data is stored inside a ICO or CUR file, Windows XP (the first Windows version to support ICO/CUR files with more than 1 bit of transparency) and above interpret this byte as an alpha value.
- ^ a b 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.
- ^ a b
"Windows XP icon and cursor support". Microsoft. November 18, 2005. Archived from the original on 2011-06-30. Retrieved 2023-07-03.
The cursor is loaded properly at whatever color depth the cursor was authored. However, the system cannot distinguish between multiple candidates in the same cursor file or resource that differ only by their color depths. Icons, however, fully support multiple icon candidates with varying color depths.
- ^ a b 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.
References
[edit]- ^ "MIME Sniffing Standard". WHATWG. January 17, 2014. Archived from the original on 2014-03-27. Retrieved 2014-04-18.
- ^ Fekete, Gyorgy (March 11, 2009). "Operating System Interface Design Between 1981-2009". Webdesigner Depot. Retrieved June 6, 2011.
- ^ a b c d e f g h Hornick, John (September 29, 1995). "Icons". Windows User Interface Technical Articles (MSDN). Microsoft Corporation. Retrieved June 5, 2011.
- ^ "Windows 95 Architecture Components". Microsoft TechNet. Microsoft Corporation. Retrieved June 6, 2011.
- ^ "Shell Icon BPP". Windows 2000 Registry Reference (Microsoft TechNet). Microsoft Corporation. Retrieved June 6, 2011.
- ^ a b "Creating Windows XP Icons". Windows XP Technical Articles (MSDN). Microsoft Corporation. July 2001. Retrieved 2022-11-27.
- ^ a b c d Chen, Raymond (October 22, 2010). "The evolution of the ICO file format, part 4: PNG images". The Old New Thing - Microsoft Developer Blogs. Retrieved 2022-11-27.
- ^ "Icons (Design basics) - Win32 apps". learn.microsoft.com. 9 February 2021.
Icons have a maximum size of 256x256 pixels, making them suitable for high-dpi (dots per inch) displays. These high-resolution icons allow for high visual quality in list views with large icons... Only a 32-bit copy of the 256x256 pixel image should be included, and only the 256x256 pixel image should be compressed to keep the file size down.
- ^ GetSystemMetrics function documentation
- ^ Chen, Raymond (August 19, 2021). "What is the deal with the SM_CXCURSOR system metric?". The Old New Thing - Microsoft Developer Blogs.
- ^ a b Butcher, Simon (3 Sep 2003). "image/vnd.microsoft.icon". Retrieved 3 Jan 2014.
- ^ Lawrence, Eric (11 Feb 2011). "IE9 RC Minor Changes List". IEInternals. MSDN Blogs. Retrieved 20 Aug 2016.
See the second comment.We use "image/x-icon" because that's the MIME type we've always used. Someone at some point (AFAIK, not related to Microsoft) proposed registration of the MIME type as "vnd.microsoft.icon", but Windows doesn't actually use that, it uses image/x-icon.
- ^ Windows Imaging Component - ICO Format Overview
- ^ Chen, Raymond (2010-10-19). "The evolution of the ICO file format, part 2: Now in color!". The Old New Thing. Retrieved 2022-12-30.
- ^ "Resource File Formats - Win32 apps". learn.microsoft.com. 2020-08-19. Retrieved 2023-05-22.
- ^ Chen, Raymond (July 20, 2012). "The format of icon resources". The Old New Thing - Microsoft Developer Blogs. Retrieved 2023-05-20.
- ^ "NEWHEADER structure". Microsoft Learn.
- ^ "RESDIR structure". Microsoft Learn.
- ^ "LOCALHEADER structure - Win32 apps". learn.microsoft.com. 2020-12-11. Retrieved 2023-05-22.
- ^ Chen, Raymond (May 2008). "Windows Confidential - 16-Bit Icons Are So Passé". TechNet Magazine. Retrieved November 27, 2022.
External links
[edit]- Icon design guidelines for Windows Vista icons
- Icon design guidelines for Windows 10 app icons
- Icons (1995 Microsoft Technical Article)
- The evolution of the ICO file format (Part 1, Part 2, Part 3, Part 4)
- The format of icon resources
- The format of icon resources, revisited
- A Look Inside Windows Icons, Part 1 - PC Mag Jan 26, 1993 Vol.12 No. 2
- A Look Inside Windows Icons, Part 2 - PC Mag Feb 9, 1993 Vol.12 No. 3
- Enable High Color Icons in Windows 95 and later
- Enhance Java GUIs with Windows Icons
| Raster |
|
|---|---|
| Raw | |
| Vector | |
| Compound | |
| Metadata |
|
ICO (file format)
View on Grokipediafrom Grokipedia
Fundamentals
Definition and Purpose
The ICO file format is a proprietary image file format developed by Microsoft for storing computer icons in Microsoft Windows environments.[1] It functions as a container format that bundles one or more raster images, enabling the inclusion of multiple variants within a single file to support scalable and adaptable visual representations across different display contexts.[2] The core purpose of the ICO format is to facilitate the display of icons in graphical user interfaces by accommodating images of varying sizes, such as 16×16 pixels up to 256×256 pixels, and color depths ranging from 1-bit monochrome to 32-bit with alpha transparency.[2] This multiplicity allows applications and operating systems to select the most appropriate image based on resolution, color support, or theme requirements, ensuring optimal rendering without distortion or performance issues.[2] Typical ICO files are compact, often ranging from a few kilobytes to several tens of kilobytes, due to the relatively small dimensions and uncompressed or lightly compressed bitmap data involved.[3] While primarily designed for static icons representing UI elements like applications or files, the format optionally supports cursors—pointer images with defined hotspots for interaction—distinguished by a type field in the file header (value 1 for icons, 2 for cursors).[3] In practice, ICO files are commonly used for Windows desktop shortcuts, embedded application icons within executable (EXE) files, and website favicons for browser compatibility across platforms.[2][4]MIME Types and File Extensions
The primary MIME type for ICO files isimage/vnd.microsoft.icon, which was officially registered with the Internet Assigned Numbers Authority (IANA) in 2003 to standardize identification of this Microsoft-originated image format.[5] This registration explicitly notes that while image/x-icon had been commonly used prior, the official type clarifies handling for ICO containers, which may embed multiple BMP or PNG images for icons and cursors.[5]
A widely adopted unofficial MIME type, image/x-icon, remains prevalent in web applications, particularly for favicons specified via HTML attributes like <link rel="icon" type="image/x-icon" href="favicon.ico" rel="nofollow">, due to its early adoption by browsers before formal standardization.[5] The standard file extension associated with ICO files is .ico, enabling consistent recognition by operating systems and software; the related .cur extension is used for static cursor variants, which share a nearly identical structure but include hotspot coordinates for pointer interaction as a subtype.[6]
Prior to the 2003 IANA registration, the absence of a designated MIME type resulted in server and browser inconsistencies, such as varying interpretations of ICO data streams leading to failed favicon rendering or incorrect file associations in early web environments.[5] The standardization addressed these by establishing a vendor-specific prefix (vnd.[microsoft](/page/Microsoft)), promoting uniform treatment across HTTP responses and file systems.
Proper MIME type usage significantly impacts cross-platform compatibility for ICO files beyond Windows. On Linux, recognition via image/vnd.microsoft.icon or image/x-icon enables rendering through libraries like those in ImageMagick or tools such as icoutils, which extract and display embedded images for desktop integration.[7] Similarly, on macOS, the built-in Preview application supports opening ICO files when served with the correct MIME type, allowing users to view and export the container's multiple resolutions without additional software.[8]
Historical Development
Origins in Microsoft Windows
The ICO file format was developed by Microsoft in the mid-1980s as part of the initial implementation of Microsoft Windows 1.0, released on November 20, 1985, marking the company's first graphical user interface operating system that required a standardized method for representing icons in the user interface. This format emerged to support the display of small, fixed-size images for application shortcuts and desktop elements on the limited hardware of the era, primarily monochrome displays with resolutions such as 720×348 or 640×350 pixels. The design drew directly from device-independent bitmaps (DIBs), which allowed icons to be rendered consistently across varying display devices without reliance on specific hardware characteristics.[9] In its inaugural version for Windows 1.0, the ICO format supported only monochrome icons at a standard size of 32×32 pixels, consisting of two bitmaps: an AND mask for defining transparent areas and an XOR image for the visible content, stored contiguously as a single double-height DIB with uncompressed BI_RGB encoding.[9] These icons were integrated into the Windows environment via the resource compiler, which converted standalone ICO files into embedded resources (RT_GROUP_ICON and RT_ICON types) for executable files, ensuring efficient loading and management within applications like the accessory programs bundled with Windows 1.0.[9] Early implementations lacked support for color or alpha-channel transparency beyond the binary mask, limiting visual fidelity to black-and-white representations suitable for the era's two-color displays.[9] A significant milestone occurred with the release of Windows 3.0 in May 1990, which expanded the ICO format to include color support up to 16 colors (4 bits per pixel), enabling more expressive icons while maintaining backward compatibility with monochrome variants through multi-image files.[10] Color icons followed a similar DIB-based structure, appending a color table and pixel data before the mask, but retained the uncompressed BMP-like encoding without advanced features like palette optimization or variable compression. This evolution reflected the growing capabilities of VGA displays and the need for enhanced user interface elements in the Program Manager shell introduced in Windows 3.0.[10]Evolution and Format Extensions
The ICO file format, originally limited to monochrome and low-color bitmaps, began evolving in the mid-1990s to accommodate richer visual capabilities aligned with advancing display technologies. With the release of Windows 95 in 1995, the format gained support for 8-bit color depth, enabling 256-color icons that provided smoother gradients and more vibrant appearances compared to prior 4-bit (16-color) limitations. Windows 95 and NT 4.0 also introduced support for larger icon sizes up to 256×256 pixels, allowing for higher detail on improving displays.[10] This enhancement allowed icons to better match the era's typical 256-color display modes, though full-color rendering often required the optional Plus! pack for optimal results.[11] Subsequent advancements in Windows XP (2001) further refined transparency and sizing standards. The operating system introduced 32-bit ARGB bitmaps with an 8-bit alpha channel, replacing the binary mask with per-pixel alpha blending for more precise, anti-aliased edges and smoother integration into user interfaces.[12] Additionally, 48x48 pixel icons became a standardized size alongside 16x16 and 32x32, facilitating clearer visibility on higher-resolution displays without excessive scaling artifacts.[13] Windows Vista (2007) marked a significant leap by officially incorporating PNG-compressed images within ICO files, leveraging the ICONDIRENTRY structure to embed raw PNG data (in 32bpp ARGB format) instead of uncompressed BMPs.[14] This addition drastically reduced file sizes—often by factors of 10 or more for multi-resolution icons—while maintaining lossless quality and alpha transparency, addressing longstanding bloat from embedding multiple BMP variants.[15] Post-Vista developments in Windows 10 (2015) and Windows 11 (2021) extended compatibility to high-DPI environments, supporting embedded PNGs up to 256×256 pixels, which the system can scale for high-DPI displays, alongside theme-aware icons that adapt to light/dark modes via system APIs.[2] As of 2025, the core PNG specification from Vista remains the standard, with no major structural overhauls.[2] Beyond Microsoft ecosystems, the ICO format has seen cross-platform adoption since the late 1990s, notably as favicon.ico for web browsers starting with Internet Explorer 5 in 1999, where 16x16 ICO files enhanced bookmark and tab identification.[16] Open-source libraries like ImageMagick have supported ICO reading, writing, and multi-resolution handling since the 1990s, enabling seamless integration in Unix-like systems and tools for format conversion.[17] Despite these extensions, no widespread deprecation has occurred by 2025, as ICO's multi-image container remains efficient for icons. However, challenges persist in cursor applications, where hotspots (defining click points) render inconsistently on non-Windows platforms, often defaulting to top-left origins and causing misalignment in cross-platform software.[18]Standalone File Format
Overall Structure
The ICO file format functions as a non-compressed container for one or more small images, organized into a fixed header followed by a series of directory entries and then sequential blocks of image data.[3] This structure enables efficient storage of multiple resolutions and color depths within a single file, supporting the multi-image purpose of icons in graphical user interfaces.[3] The logical flow of the format begins with the header, which declares the total number of images contained in the file; this is followed by the directory entries, each describing the properties (such as dimensions and color depth) and location (via offset) of an individual image; the image data blocks then appear in the order referenced by these offsets, without any interleaving between metadata and content.[19] Over time, the format has evolved to include support for PNG-compressed image data alongside traditional BMP structures.[20] ICO files come in two variants based on the type field in the header: type 1 for standard icons, which omit hotspot coordinates, and type 2 for cursor files (often with .cur extension), where each directory entry incorporates two-byte fields for the x- and y-hotspot coordinates to define the precise pointer location.[3] The header's two-byte count field limits the maximum number of images to (65,535), though practical files rarely exceed a few dozen images across common resolutions like 16×16, 32×32, and 256×256 pixels, keeping overall file sizes typically under 100 KB.[3] Basic validation of an ICO file requires it to begin with reserved bytes of 00 00, followed by a valid type value (1 or 2) and a non-zero count; potential corruption is identifiable through discrepancies between the offsets in directory entries and the actual positions or sizes of the subsequent image data blocks.[19] A representative file layout can be described as follows: the header spans the first six bytes (positions 0–5), the directory entries occupy the next segment from byte 6 to 6 + 16 × N (where N is the image count from the header), and the image data blocks are then positioned at the absolute file offsets specified in the entries, allowing direct access without seeking through unrelated content.[3]ICONDIR Header
The ICONDIR header is a fixed-size 6-byte structure that serves as the initial segment of a standalone ICO or CUR file, providing essential metadata to initialize the file and indicate its contents. This header precedes the array of ICONDIRENTRY structures and the embedded image data, enabling parsers to determine the file's type and the number of contained images. Defined in early Windows SDK documentation, the structure uses WORD fields (16-bit unsigned integers) in little-endian byte order, consistent with the Windows platform's native endianness.[3][9] The header's byte layout is as follows:| Offset | Size (bytes) | Field Name | Value/Range | Description |
|---|---|---|---|---|
| 0 | 2 | idReserved | 0x0000 | Reserved field for future use; must be zero to ensure compatibility. |
| 2 | 2 | idType | 0x0001 (ICO) or 0x0002 (CUR) | Specifies the resource type: 1 for icon files (.ICO), which are rendered as static images, or 2 for cursor files (.CUR), which include hotspot coordinates for pointer positioning. Other values are invalid and may cause parsing failures in compliant readers. |
| 4 | 2 | idCount | 0x0000 to 0xFFFF | Indicates the number of image entries in the file; a value of 0 denotes an empty file with no images, while higher values allow for multi-resolution sets (e.g., 16x16, 32x32 pixels). |
00 00 01 00 03 00, representing idReserved=0x0000, idType=0x0001, and idCount=0x0003 in little-endian order.[3]
ICONDIRENTRY Entries
The ICONDIRENTRY entries constitute an array of fixed-size records immediately following the ICONDIR header, cataloging the properties and positions of each embedded image in the ICO file. The array length is determined by the idCount field in the ICONDIR header, with each entry spanning exactly 16 bytes to enable straightforward parsing and indexing of multiple images supporting various resolutions and color depths. This design facilitates efficient access to specific images without scanning the entire file, as the entries collectively describe the file's image inventory before the actual data payloads begin.[9][19] Each ICONDIRENTRY follows a rigid byte-level layout to encode essential metadata:| Byte Offset | Size (bytes) | Field Name | Type | Description |
|---|---|---|---|---|
| 0 | 1 | bWidth | BYTE | Image width in pixels (values 1-255; 0 indicates 256 pixels, supported since Windows 95 and NT 4.0). |
| 1 | 1 | bHeight | BYTE | Image height in pixels (values 1-255; 0 indicates 256 pixels). For cursor images, this is the height of the XOR plane; the embedded DIB uses twice this height. |
| 2 | 1 | bColorCount | BYTE | Number of colors in the color palette (0 indicates 256 colors or no palette if bits per pixel ≥8). |
| 3 | 1 | bReserved | BYTE | Reserved field; must always be set to 0. |
| 4-5 | 2 | wPlanes | WORD | Number of color planes (typically 0 or 1; 0 permitted for certain formats like PNG). |
| 6-7 | 2 | wBitCount | WORD | Bits per pixel (0 is reserved; valid range 1-32; 0 permitted for PNG images). |
| 8-11 | 4 | dwBytesInRes | DWORD | Size of the image data in bytes (for PNG, the size of the complete PNG stream). |
| 12-15 | 4 | dwImageOffset | DWORD | Byte offset from the start of the ICO file to the beginning of the image data. |
Embedded Image Data
The embedded image data in an ICO file follows immediately after the ICONDIR header and its ICONDIRENTRY entries, with each entry's offset field specifying the absolute file position and the length field indicating the byte size of the raw image payload. For traditional BMP-style images, this payload begins with a BITMAPINFOHEADER structure, followed by the XOR mask containing the color data in an uncompressed bitmap format matching the entry's color depth, and then the AND mask as a 1-bit-per-pixel (1 bpp) monochrome bitmap for transparency handling.[19][23] The AND mask mechanics involve inverted bit logic, where a bit value of 1 denotes a transparent pixel (allowing the background to show through) and 0 indicates an opaque pixel that displays the corresponding color from the XOR mask; the XOR mask supplies the visible pixel colors or indices only for opaque areas, with no compression applied in this classic mode to ensure direct rendering compatibility. For cursor images stored in the ICO format (typically in .cur files), the payload includes an additional 4 bytes immediately before the XOR and AND masks, consisting of two 16-bit unsigned integers for the hotspot coordinates (x and y, ranging from 0 to 65535), which define the precise pointing position relative to the image's top-left corner; the AND mask further supports pointer positioning by outlining the effective shape.[23] PNG support was introduced in Windows Vista to enable more efficient storage with native alpha transparency. For PNG images, bHeight is the actual height of the PNG image, and no separate AND mask is used as transparency is handled by the PNG alpha channel, with the embedded data consisting of a complete PNG stream beginning with the standard signature bytes (0x89 0x50 0x4E 0x47 0x0D 0x0A 0x1A 0x0A) and utilizing the PNG's internal alpha channel for transparency without additional masks. For example, in a 16x16 monochrome icon using the classic BMP style, the XOR mask requires 32 bytes (16 × 16 / 8) for the color data, and the AND mask another 32 bytes for the 1 bpp transparency bitmap, yielding a total image data size of 64 bytes excluding the header.[24]BMP Format Support
The BMP format support in ICO files relies on an uncompressed device-independent bitmap (DIB) variant, which embeds image data without the standard 14-byte BMP file header, beginning directly with the 40-byte BITMAPINFOHEADER structure.[23][25] This approach ensures compatibility with Windows graphics device interface (GDI) functions for rendering icons, where the DIB provides device-independent pixel data.[9] Key fields in the BITMAPINFOHEADER are fixed or derived from the preceding ICONDIRENTRY: biSize is set to 40, indicating the size of the header; biWidth matches the icon's width from the entry; biHeight is twice the icon's height to accommodate both the XOR image and AND mask in a single bitmap; biPlanes is 1; biBitCount specifies the color depth (typically 1, 4, 8, 16, 24, or 32 bits per pixel) from the entry; and biCompression is 0 (BI_RGB), enforcing no compression such as RLE.[23][9] For bit depths of 16 bits per pixel or higher, no color palette follows the header, as these formats use direct RGB values without indexing.[25] Lower depths (1, 4, or 8 bpp) include a palette of RGBQUAD entries immediately after the header, with the number of entries equal to 2^biBitCount (e.g., 256 entries for 8 bpp, each 4 bytes: one byte each for blue, green, red, and reserved).[23] Pixel data follows the palette (if present), starting with the XOR mask rows representing the icon's colored image, stored in bottom-up order per the Windows DIB standard—meaning the first row in the data is the bottommost scanline of the image.[25][23] Each row is padded with zero bytes to align to a 4-byte (DWORD) boundary, ensuring efficient memory access; for example, a 32-pixel-wide row at 8 bpp requires 32 bytes (no padding), while a 1 bpp row spans 4 bytes (32 bits, no padding).[23] The XOR data spans the full biHeight/2 rows for the icon height. Immediately after, the AND mask rows follow as a monochrome 1 bpp bitmap of the same dimensions, also bottom-up and 4-byte padded, defining transparency by indicating opaque (0) or transparent (1) pixels.[9][23] ICO files do not support RLE compression for this DIB, limiting encoding to raw BI_RGB pixels.[9] This BMP-based encoding results in larger file sizes due to the absence of compression and the duplication of data for XOR and AND masks, with transparency simulated via the binary AND mask rather than per-pixel alpha channels.[23] For a representative 32×32 pixel icon at 8 bpp, the embedded data totals approximately 2,216 bytes: 40 bytes for the header, 1,024 bytes for the 256-entry palette, 1,024 bytes for the XOR rows (32 bytes per row × 32 rows), and 128 bytes for the AND rows (4 bytes per row × 32 rows), excluding the ICO directory overhead.[23] Such limitations made BMP the legacy standard until PNG integration addressed compression and native alpha needs.[14]PNG Format Support
Support for the Portable Network Graphics (PNG) format was introduced in the ICO file format with the release of Windows Vista in 2007, enabling the embedding of compressed PNG images alongside or instead of traditional BMP data for more efficient storage of high-resolution icons. This addition addressed the growing need for larger icons, such as 256×256 pixels, by leveraging PNG's compression capabilities while maintaining compatibility with the existing ICO container structure. The PNG data is stored directly within the file, with the ICONDIRENTRY's offset field pointing to the beginning of the PNG stream, which starts with the standard 8-byte PNG signature (\x89PNG\r\n\x1a\n) immediately followed by the IHDR chunk containing image metadata.[14] PNG images in ICO files must adhere to specific requirements to ensure proper rendering. The image dimensions must be square, with the width and height values matching those specified in the ICONDIRENTRY. The PNG must use truecolor with alpha (color type 6 in the IHDR) and an 8-bit depth per channel, equivalent to 32 bpp ARGB format, to support per-pixel transparency natively. Ancillary chunks that do not alter core parsing, such as textual metadata, are permitted, but the structure relies on critical chunks like IHDR and IDAT for essential data. Microsoft recommends PNG compression particularly for 32-bit 256×256 icons to optimize file size without loss of quality.[14][2] The primary advantages of PNG integration include DEFLATE compression (based on LZ77 and Huffman coding), which significantly reduces file size compared to uncompressed BMP equivalents—for instance, a representative 48×48 truecolor PNG icon typically occupies around 5 KB, versus approximately 10 KB for the same image in BMP format. Additionally, PNG's built-in 8-bit alpha channel per pixel provides precise transparency control, obviating the need for a separate monochrome AND mask and reducing potential errors in mask generation. This native alpha handling simplifies icon design and improves rendering accuracy in modern Windows environments.[14] When parsing PNG entries, ICO readers treat the embedded data as a complete PNG file, decoding the image dimensions and palette (if any) from the IHDR chunk and extracting RGB and alpha values directly from the IDAT compressed data chunks. Any tRNS chunk for transparency in non-alpha PNGs is disregarded, as the format mandates the alpha channel for ICO compatibility. This direct extraction ensures efficient rendering without additional bitmap conversion steps.[14] ICO files support PNG subsets up to 256×256 pixels, aligning with Windows icon scaling limits, though smaller sizes like 16×16 to 48×48 are common for multi-resolution icons. Full compatibility requires Windows Vista or later, as pre-Vista systems expect BMP-only data and may fail to parse PNG streams. Limitations include the absence of animation support, despite PNG's potential for animated variants, and adherence to guidelines prohibiting interlacing (Adam7) to avoid parsing issues in icon viewers.[2][14]Resource File Integration
Group Icon and Cursor Resources
In Windows executable files following the Portable Executable (PE) format, icons and cursors are embedded as resources within the .rsrc section, which organizes various application assets in a hierarchical tree structure.[26] Multiple icon images are grouped together using a resource of type RT_GROUP_ICON (ordinal 14), while the individual icon bitmaps are stored separately as resources of type RT_ICON (ordinal 3).[27] This setup allows the operating system to select the most suitable icon variant based on display resolution or color depth without loading unnecessary data.[21] The group resource of type RT_GROUP_ICON functions as a directory that links to the actual icon data, containing entries with resource identifiers (nId) that reference the corresponding RT_ICON resources rather than direct file offsets.[21] In contrast, the individual RT_ICON resources hold the raw bitmap and mask data for a single icon image. For cursors, the equivalent mechanism uses RT_GROUP_CURSOR (ordinal 12) to group multiple cursor variants and RT_CURSOR (ordinal 1) for the individual cursor bitmaps, which additionally specify hotspot coordinates for precise pointer positioning.[27] Cursors also include hotspot needs similar to those in embedded image data for accurate interaction handling.[28] To extract these resources, applications first load the resource table from the PE file's .rsrc section using Windows APIs such as FindResource to locate the RT_GROUP_ICON entry by name or ID. The group is then parsed to obtain the directory of icon entries, after which LoadResource and LockResource are used to access the individual RT_ICON resources via their offsets or identifiers within the resource tree.[21] Higher-level functions like ExtractIconEx simplify this process by automatically handling the enumeration and loading of multiple variants from a group. Embedding icons and cursors as resources offers advantages over standalone files by enabling shared storage within binaries, which reduces file duplication and improves memory efficiency since only required images are loaded at runtime.[21] The Microsoft Resource Compiler (rc.exe) automates the generation of these group and individual resources from resource script (.rc) files containing ICON or CURSOR directives, compiling them into a .res file that is linked into the executable.[29] A common use case is embedding application icons in the headers of Windows EXE files, where the group resource provides variants for different UI contexts such as taskbar or desktop display.[28] Unlike standalone .ico files, which feature a top-level ICONDIR header directly followed by image data, embedded resources lack this top-level directory and are instead integrated into the broader PE resource tree for modular access.[21] For example, a single EXE file might include one RT_GROUP_ICON resource linking five icon variants—such as 16x16, 32x32, 48x48, 256x256 at 32-bit color, and a monochrome version—to support various system scaling levels.[28]NEWHEADER Structure
The NEWHEADER structure serves as the initial header for group icon and cursor resources in Portable Executable (PE) files, adapting the format of standalone ICO files for integration within Windows resource sections. It consists of a fixed 6-byte layout that mirrors the core fields of the ICONDIR header from standalone ICO files but is tailored for resource-based organization, where individual icon or cursor images are stored as separate resources rather than embedded data blocks. This structure precedes one or more RESDIR entries, with the count field determining the number of such entries, each describing a linked individual resource by identifier rather than file offset.[20] The layout of the NEWHEADER is defined as follows:| Offset | Size | Field Name | Type | Description |
|---|---|---|---|---|
| 0x00 | 2 | [Reserved | WORD](/page/Reserved_word) | Must be set to 0; reserved for future use.[20] |
| 0x02 | 2 | resType | WORD | Resource type identifier: 1 for icon groups (RT_GROUP_ICON) or 2 for cursor groups (RT_GROUP_CURSOR).[20] |
| 0x04 | 2 | resCount | WORD | Number of RESDIR entries that follow, corresponding to the count of individual icon or cursor resources in the group.[20] |
00 00 01 00 04 00, where the first two bytes are the reserved value, the next two indicate the icon type, and the final two specify the entry count. This header enables the Windows resource loader to identify and enumerate the grouped resources efficiently within the PE file's .rsrc section.[20][21]
Unlike the ICONDIR header in standalone ICO files, which uses fixed ICONDIRENTRY structures with direct file offsets to image data, the NEWHEADER employs RESDIR entries that reference individual resources by ordinal identifiers (e.g., "#101" for resource ID 101), allowing flexible naming via strings or integers in the broader PE resource directory tree. This design supports random access to components without embedding offsets, relying instead on the PE format's resource directory for locating the actual RT_ICON or RT_CURSOR data. The structure must align properly within the PE section boundaries to ensure correct parsing by tools such as Resource Hacker.[20][21]
RESDIR Structure
The RESDIR structure defines an individual component within a group icon or cursor resource in Windows Portable Executable (PE) files, serving as an entry that describes the properties and links to the corresponding image data stored separately as an RT_ICON or RT_CURSOR resource.[30] Each RESDIR entry is 14 bytes long and follows the NEWHEADER structure in the resource data, with the number of entries specified by the ResCount field in NEWHEADER.[30] Unlike the standalone ICO format's ICONDIRENTRY, which includes a direct file offset to embedded image data, RESDIR uses a resource identifier to reference the actual icon or cursor data within the PE file's resource directory tree, enabling modular storage without embedding the images in the group resource itself.[30] The structure consists of the following fields:typedef struct {
union {
ICONRESDIR Icon; // 4 bytes: Width (BYTE), Height (BYTE), ColorCount (BYTE), [Reserved](/page/Reserved) (BYTE)
CURSORDIR Cursor; // 4 bytes: Width (BYTE), Height (BYTE), Reserved1 (BYTE), Reserved2 (BYTE)
};
WORD Planes; // 2 bytes: Number of color planes in the image
WORD BitCount; // 2 bytes: Bits per [pixel](/page/Pixel) in the image
DWORD BytesInRes; // 4 bytes: Size of the resource data in bytes
WORD IconCursorId; // 2 bytes: Ordinal identifier of the corresponding RT_ICON or RT_CURSOR resource
} RESDIR;
typedef struct {
union {
ICONRESDIR Icon; // 4 bytes: Width (BYTE), Height (BYTE), ColorCount (BYTE), [Reserved](/page/Reserved) (BYTE)
CURSORDIR Cursor; // 4 bytes: Width (BYTE), Height (BYTE), Reserved1 (BYTE), Reserved2 (BYTE)
};
WORD Planes; // 2 bytes: Number of color planes in the image
WORD BitCount; // 2 bytes: Bits per [pixel](/page/Pixel) in the image
DWORD BytesInRes; // 4 bytes: Size of the resource data in bytes
WORD IconCursorId; // 2 bytes: Ordinal identifier of the corresponding RT_ICON or RT_CURSOR resource
} RESDIR;
Icon Libraries
.ICL File Composition
Icon library (.ICL) files function as resource-only dynamic link libraries (DLLs) in the Portable Executable (PE) format, featuring no executable code segments and confining all content to the .rsrc section.[33] This design enables .ICL files to serve as dedicated containers for multiple icons, leveraging the standard PE structure for resource management without the overhead of code execution.[26] The composition begins with a conventional DLL header, including the DOS stub, PE optional header, and section table, followed by the resource directory in the .rsrc section.[26] This directory organizes numbered icon resources, typically assigned sequential IDs from 1 to N, where each ID corresponds to a distinct icon group.[21] Each group comprises an RT_GROUP_ICON resource (type 14) that describes the collection of icon variants, paired with one or more RT_ICON resources (type 3) holding the actual bitmap image data.[28] Within each RT_GROUP_ICON resource, the data structure employs a NEWHEADER to specify the resource count and offsets, succeeded by multiple RESDIR entries that detail individual icon variants, including dimensions, bit depth, and pointers to the corresponding RT_ICON data.[31][30] This format supports a range of icon sizes and formats, ensuring compatibility with display requirements. .ICL files can also incorporate cursors via RT_GROUP_CURSOR (type 21) and RT_CURSOR (type 2) resources, allowing mixed libraries of icons and pointers within the same resource tree.[28] .ICL files are produced through resource compilers like rc.exe, which processes a resource script (.rc file) into an intermediate .res file, subsequently linked into a PE DLL using tools such as link.exe with flags like/DLL and /NOENTRY to omit code segments.[33] Resource scripts may include directives to define the output as a library, ensuring the focus remains on embedded assets. File sizes scale with the quantity and resolution of icons; libraries with dozens of high-resolution icons can reach several hundred kilobytes.[29]
A key benefit of .ICL files lies in their centralized storage model, akin to system DLLs, which streamlines icon distribution and maintenance in applications or themes.[34] Resources within .ICL files are accessible via Windows APIs, such as ExtractIcon or LoadImage, enabling runtime extraction without file modification.
As an illustration, Windows system libraries like shell32.dll—which share the .ICL composition principles—house hundreds of icons across numerous RT_GROUP_ICON groups, demonstrating scalable organization for extensive collections.[34]
Creation and Usage
Icon libraries in the .ICL format are created by compiling resource scripts that define icon groups and individual icons, typically using Microsoft tools or third-party resource editors. The Microsoft Resource Compiler (rc.exe) processes .rc script files containing statements like GROUPICON to define logical icons composed of multiple BITMAP resources for different sizes and colors, and ICON statements to reference individual icon files. For example, a .rc file might include lines such asID1 ICON "icon1.ico" where icon1.ico contains multiple image sizes and color depths. This script is compiled into a .res file using rc.exe, which is then linked into a dynamic-link library (DLL) without executable code using the Microsoft Linker (link.exe) with the /DLL option and a module-definition (.def) file specifying the output as a library; the resulting DLL can be renamed to .icl for use as an icon library.[29]
Alternative tools facilitate this process through graphical interfaces, such as the Visual Studio Resource Editor, which allows developers to visually add icons to a .rc file within an integrated development environment before compilation. ResEdit, a free resource editor, enables creation of .rc scripts with icons and exports them directly to executable formats including libraries. Specialized icon software like IcoFX provides a resource editor where users create a new resource file, add icons via drag-and-drop or import, assign resource IDs (e.g., #1 for the first icon), and save as a 32-bit .ICL file. Similarly, Axialis IconWorkshop's Librarian tool creates empty .ICL files in a project folder, to which icons are subsequently added and compiled.[35][36][37][38]
In usage scenarios, .ICL files serve as external repositories for icons in Windows applications, allowing developers to reference them without embedding large resources directly into executables, which reduces file sizes and simplifies maintenance. System-wide icon libraries, such as imageres.dll (introduced in Windows Vista), which in Windows 10 version 1903 and later stores icons in C:\Windows\SystemResources\imageres.dll.mun, provide default icons for folders, devices, and actions across the operating system, loaded dynamically by shell components.[39][40][41]
Icons from .ICL files are extracted and managed programmatically using Windows API functions, such as LookupIconIdFromDirectoryEx, which scans the resource directory for the best-fitting icon based on display device parameters like color depth and size, returning its identifier for further loading with CreateIconFromResourceEx. Third-party tools like IcoFX's resource viewer allow browsing and extraction of icons from .ICL files for editing or reuse.[42][37]
Best practices for .ICL creation include incorporating multiple resolutions (e.g., 16x16, 32x32, 48x48, and 256x256 pixels) within each GROUPICON to ensure scalability across user interfaces, as single-size icons may appear pixelated on high-DPI displays. As of 2025, developers should prefer PNG-formatted icons over legacy BMP for new libraries, leveraging Windows' native PNG support since Vista to achieve smaller file sizes and better compression without quality loss.[43]
Limitations of .ICL files include their non-human-readable binary structure, requiring specialized tools for editing, and native support restricted to Windows environments, with no built-in compatibility for other operating systems. Additionally, 16-bit .ICL files are incompatible with 64-bit Windows versions.[44][45]