Every BMP file starts with a 14-byte file header, called BITMAPFILEHEADER in
the Windows headers. It marks the file as a bitmap and says where the pixels start. The
DIB header follows straight after it.
00000000 42 4D 46 00 00 00 00 00 00 00 36 00 00 00BM, 70 bytes long, pixels at offset 54Fields
All numbers are little-endian. The header has no padding, so it is exactly 14 bytes and the fields after the first are not aligned to 4 bytes.
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
| 0 | 2 | char[2] | bfType | The signature BM (42 4D). OS/2 files can carry other values, listed below. |
| 2 | 4 | u32 | bfSize | The size of the whole file in bytes. Some programs write a wrong value or zero, so readers should not depend on it. |
| 6 | 2 | u16 | bfReserved1 | Reserved, zero. |
| 8 | 2 | u16 | bfReserved2 | Reserved, zero. |
| 10 | 4 | u32 | bfOffBits | The offset from the start of the file to the pixel data. |
Signatures
Windows bitmaps always use BM. OS/2 defined further types for its icon and
pointer files, which use the same header; in those, the two reserved fields hold the
hotspot.
| Value | Bytes | Meaning |
|---|---|---|
BM | 42 4D | Windows or OS/2 bitmap |
BA | 42 41 | OS/2 bitmap array |
CI | 43 49 | OS/2 colour icon |
CP | 43 50 | OS/2 colour pointer |
IC | 49 43 | OS/2 icon |
PT | 50 54 | OS/2 pointer |
Finding the pixels
Use bfOffBits to find the pixel data rather than adding up the sizes of
the parts before it. Writers may leave a gap after the colour table, for example to
align the pixels, and the offset is the one value every reader agrees on.
Where a bitmap is held in memory, on the clipboard or inside an ICO file, there is no file header: the data starts directly with the DIB header.