BMP file format
Windows Bitmap, an uncompressed (or lightly compressed) raster image format.
- MIME type
- image/bmp
- Extensions
- .bmp
- Category
- Images
Magic-number signature
| 0x00000000 | 424D | BM | 'BM' header |
About the BMP format
BMP stores pixels essentially raw, which makes files large but trivial to read and write; it is still common as an intermediate format on Windows. The two-byte header 'BM' is followed by the file size and pixel-array offset, and then by a second header — the DIB header — whose own first field is its length, which is how one format quietly covers six different header layouts spanning thirty years. Rows are stored bottom-up unless the height is negative, and every row is padded out to a multiple of four bytes. Those two rules account for most of the confusion anyone meets when writing a BMP reader for the first time.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 2 | Signature | 42 4D, the ASCII letters BM. Two bytes is a short magic number by modern standards, so a detector that stops here will happily identify any text file beginning with the word BMP or a name like Bmw as a bitmap; the size field right after it is the usual sanity check. |
| 2 | 4 | File size | Little-endian total size of the file in bytes, including both headers. Unlike almost every other format's size field this one is supposed to be exact, so comparing it against the size on disk is a free integrity check that costs four bytes to read. |
| 6 | 4 | Reserved | Two 16-bit fields, both required to be zero. Some editors use them as scratch space for their own purposes, and readers universally ignore them, so a non-zero value here identifies the writing application more often than it indicates damage. |
| 10 | 4 | Offset to the pixel array | Little-endian byte position where the actual pixels start, counted from the beginning of the file. For a plain 24-bit image with the classic 40-byte DIB header this is 54: fourteen plus forty, with no palette in between. A larger value means a palette, colour masks or an embedded ICC profile sits in the gap. |
| 14 | 4 | DIB header size | The length of the second header, and in practice the version number of the format: 12 is the ancient OS/2 BITMAPCOREHEADER, 40 is BITMAPINFOHEADER and the one you will see almost everywhere, 52 and 56 add colour masks, 108 is BITMAPV4HEADER with colour space fields and 124 is BITMAPV5HEADER with an ICC profile. |
| 18 | 4 | Width | Signed little-endian 32-bit pixel width. Signed, but negative widths are not legal — only the height carries meaning in its sign. A 12-byte OS/2 header stores width and height as 16-bit values instead, so these offsets do not apply there. |
| 22 | 4 | Height | Signed little-endian 32-bit pixel height, and the most surprising field in the format: a positive value means the rows are stored bottom-up, last row of the image first, while a negative value means top-down and the absolute value is the real height. Windows screen captures often write a negative number here. |
| 26 | 2 | Colour planes | Must be 1. It is a survivor from the days of planar video memory and no reader accepts anything else, which makes it a useful second sanity check right after the BM signature. |
| 28 | 2 | Bits per pixel | 1, 4 or 8 with a palette, 16 or 32 with colour masks, 24 for plain BGR triples, and 0 only in the special case where the compression field says the payload is an embedded JPEG or PNG. Note the channel order: BMP stores blue, green, red, which is the opposite of everything else on this site. |
| 30 | 4 | Compression method | 0 is BI_RGB, meaning no compression at all. 1 and 2 are run-length encodings for 8-bit and 4-bit images, 3 is BI_BITFIELDS with explicit channel masks, and 4 and 5 declare that the pixel array is really a whole JPEG or PNG file — a rarely used escape hatch that turns a BMP into a container. |
| 34 | 4 | Image data size | Bytes in the pixel array, and legally zero when the compression method is BI_RGB because the reader can compute it. That computation is where the padding rule bites: each row occupies its width times bits-per-pixel divided by eight, rounded up to a multiple of four. |
| 38 | 8 | Horizontal and vertical resolution | Two signed 32-bit values in pixels per metre, not per inch, so 96 dpi is stored as 3780. Both are zero in most files and are the only place a BMP records physical size. |
| 46 | 8 | Palette entry counts | How many colours the palette actually holds, then how many of them matter for display. Zero in the first field means the full two-to-the-bit-depth palette is present, which is why a 256-colour BMP with zero here still has 1024 bytes of palette between the header and the pixels. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| ICO | The image inside an ICO directory entry is very often a BMP with the fourteen-byte file header stripped off, so it starts at the DIB header — a bare 28 00 00 00 with no BM in front of it. Worse, its height field is stored at twice the real value because the pixel array is followed by a one-bit AND mask of the same dimensions. Pulling that payload out of an ICO and saving it as .bmp produces an image stretched to double height with garbage in the lower half. |
| Clipboard DIB | Windows CF_DIB clipboard data is a BMP that likewise begins at offset 14, with no BM signature and no file size. Any tool that writes clipboard bytes straight to disk produces a file whose first four bytes are 28 00 00 00; prepending a correct fourteen-byte BITMAPFILEHEADER with the right pixel offset turns it back into a normal .bmp. |
| TIFF | Both are used for uncompressed archival and scanner output and both store multi-byte numbers little-endian, but the header settles it in two bytes: 42 4D for BMP, 49 49 or 4D 4D for TIFF. The practical difference is that TIFF can hold multiple pages, arbitrary metadata and a choice of compressions, while BMP holds exactly one image and almost always no compression at all. |
| PNG | 89 50 4E 47 against 42 4D. They target the same use — lossless raster with an alpha channel available — and PNG wins on size by roughly an order of magnitude. BMP's counter-argument is that you can write a correct decoder for it in an afternoon with no dependencies, which is why firmware splash screens and embedded UIs keep using it. |
How these files break
- Forgotten row padding. Every row must be padded to a multiple of four bytes, so a 63-pixel-wide 24-bit image needs one extra byte per row. A writer that omits it produces a file whose rows drift sideways by one byte each, and the image comes out sheared into a diagonal — the single most recognisable BMP bug there is.
- A wrong pixel-array offset. The four bytes at offset 10 are the only thing pointing at the image data, and if a tool inserts a palette or an ICC profile without updating them the decoder starts reading part of the header as pixels. The result is a band of coloured noise at the bottom of the image and a shift in everything above it.
- Height sign confusion. A reader that treats the signed height as unsigned turns a top-down capture into a height of over four billion and refuses the file; one that ignores the sign entirely renders the picture upside down. Both failures come from four perfectly valid bytes at offset 22.
- Truncation. Because rows are normally stored bottom-up, a BMP cut short loses the top of the picture rather than the bottom — the opposite of what every other format on this site does. The size at offset 2 will not match the file on disk, which makes it the fastest way to confirm.
- Channel order swapped. BMP stores blue, green, red, and a converter that assumes red, green, blue produces an image where skies are orange and skin tones are blue. Nothing in the file is invalid, so no validator will report it.
Where the format stands today
BMP is a Windows native format that never had a reason to travel and never did. It has no place on the web — the same picture as a PNG is routinely ten times smaller with no quality difference — and no camera or phone emits it. What keeps it alive is the two situations where its lack of compression is the point. The first is Windows itself: the clipboard's image format is a DIB, screen-capture and scanner drivers still hand out bitmaps, and Explorer thumbnails and .exe resources are built on the same structures. The second is anywhere a decoder is expensive to have: bootloader splash screens, microcontroller displays, printer firmware and test rigs read BMP because the pixel array is just there, at a known offset, in a known order, with no entropy coder to implement. As an intermediate format in an image pipeline it is also perfectly reasonable, since writing one is instant and it is exactly lossless. What it should never be is a delivery format.
Open BMP files on this site
Every one of these runs in your browser — the file never leaves your machine.
Related formats
Formats that are easy to confuse with BMP — compare their leading bytes.