Bitmap Image

Header anatomy

Every BMP file begins with two headers placed back-to-back in a fixed sequence that has not changed since 1990.

BITMAPFILEHEADER (14 bytes) starts at byte 0 with the signature 0x42 0x4D — ASCII letters "BM" — followed by a 4-byte little-endian file size, two 2-byte reserved fields (always zero), and a 4-byte pixel data offset. This offset tells the decoder how many bytes to skip before pixel data begins. For a 24-bit image with no color table, the offset is 54 (14 + 40).

BITMAPINFOHEADER (40 bytes) is the most common DIB header variant, used in roughly 99% of BMP files in the wild. It contains image width and height as signed 32-bit integers, a 2-byte color plane count (always 1), a 2-byte bit count (1, 4, 8, 16, 24, or 32), and a 4-byte compression method constant. The compression field is 0 (BI_RGB) for uncompressed data, 1 (BI_RLE8) for 8-bit run-length encoding, 2 (BI_RLE4) for 4-bit RLE, and 3 (BI_BITFIELDS) for custom channel masks in 16-bit and 32-bit modes.

Five different DIB header versions exist: BITMAPCOREHEADER (12 bytes, OS/2 1.x, 1988), BITMAPINFOHEADER (40 bytes, Windows 3.0, 1990), BITMAPV4HEADER (108 bytes, Windows 95, adds color space and gamma), BITMAPV5HEADER (124 bytes, Windows 98, adds ICC profiles and sRGB intent), and the undocumented BITMAPV2 and V3 variants occasionally emitted by Adobe software. The header size field at offset 0x0E self-identifies the version — a decoder reads this value first to determine how many bytes to parse.

Pixel storage and row padding

BMP stores pixels in BGR byte order, not RGB. This is a direct consequence of the x86 little-endian memory layout used by Windows GDI functions. Each scanline must be padded to a 4-byte (DWORD) boundary. The padding formula is (4 - (width * bytesPerPixel) % 4) % 4. A 3-pixel-wide 24-bit image uses 9 bytes of pixel data per row plus 3 padding bytes, totaling 12 bytes per row. A 1920-pixel-wide 24-bit image uses 5760 bytes per row with zero padding because 5760 is already divisible by 4.

This alignment requirement exists because Windows GDI blitting functions — BitBlt, StretchBlt, SetDIBitsToDevice — read pixel data as aligned DWORD arrays. Unaligned access on early x86 processors incurred a significant performance penalty. Modern CPUs handle unaligned access transparently, but the padding convention persists because every BMP decoder expects it.

Bit depths range from 1-bit monochrome (2 colors) through 4-bit (16 colors) and 8-bit (256 colors) paletted modes, to 16-bit (5-5-5 or 5-6-5 layouts), 24-bit BGR, and 32-bit BGRA. The 32-bit variant stores an alpha channel in the fourth byte of each pixel, but many applications ignore it — Windows XP era software typically treated 32-bit BMP as 24-bit with an unused padding byte. The BITMAPV4HEADER or later is required for the alpha channel to be interpreted correctly.

The inverted row order

BMP's most distinctive technical feature is its bottom-to-top row order. The first row of pixel data in the file corresponds to the bottom scanline of the image. This design matches the mathematical convention where the origin (0,0) is at the lower-left corner, and it aligns with the way CRT monitors physically drew scan lines from bottom to top in the frame buffer.

A negative value in the height field reverses this behavior, storing rows top-to-bottom. Top-down BMPs are common in screen capture utilities and memory-mapped frame buffers, but some older parsers reject them. The Windows clipboard stores bitmaps in bottom-up order, so clipboard screenshots always use positive height values.

Performance characteristics

BMP's lack of compression makes it simultaneously the fastest format to decode and the worst for storage. Decoding a 4K (3840x2160) BMP at 24-bit requires reading 24,883,254 bytes sequentially and copying to a framebuffer — no decompression algorithm, no entropy decoding, no inverse transforms. On modern hardware with NVMe storage, BMP decode completes in under 5 milliseconds.

PNG compresses the same 4K image to 8-15 MB with DEFLATE. JPEG achieves 2-4 MB with perceptual quality loss. WebP hits 1.5-3 MB. BMP's 25 MB file size is pure overhead for distribution. The format trades storage and bandwidth for zero decode cost.

RLE compression modes

BMP supports two Run-Length Encoding modes: BI_RLE8 for 8-bit images and BI_RLE4 for 4-bit images. An RLE8 stream alternates between run-length bytes and pixel value bytes: the pair 05 03 means "repeat color index 3 five times." Escape codes handle end-of-line (00 00), end-of-bitmap (00 01), and absolute mode (00 N followed by N literal pixels).

RLE compression is effective for images with large solid-color regions — system icons, UI backgrounds, and monochrome scans. A solid-color 1920x1080 8-bit BMP compresses from 2 MB to under 10 KB. But for photographs or screenshots with noise, RLE often produces files larger than the uncompressed equivalent because the overhead of switching between runs exceeds the savings. This poor compression ratio for complex images, combined with the universal availability of PNG since 1996, is why RLE-compressed BMPs are nearly extinct in practice.

BMP v5 and ICC color profiles

The BITMAPV5HEADER, introduced with Windows 98, added the ability to embed ICC color profiles directly in the BMP file. The header contains fields for the color space type (LCS_CALIBRATED_RGB, LCS_sRGB, LCS_WINDOWS_COLOR_SPACE, or PROFILE_LINKED/PROFILE_EMBEDDED), gamma values for each RGB channel, and the offset and size of an embedded ICC profile blob. This means a BMP v5 file can carry the same color management data as a TIFF or PNG with an iCCp chunk.

In practice, almost no software writes BMP v5 with embedded ICC profiles. The format was already declining by 1998, and applications that needed color management moved to TIFF or PNG. The v5 header is primarily encountered in Windows system bitmaps and DirectDraw surface conversions.

When BMP makes sense

Four scenarios justify BMP in 2026. First, Windows clipboard operations: copying an image to the clipboard stores it as a DIB internally, and pasting into Paint or legacy enterprise software produces a BMP file. Second, frame buffer dumps in embedded systems where CPU cycles for decompression are unavailable — microcontroller displays that read raw pixel data from flash storage. Third, computer science education, where BMP's transparent structure makes it the standard teaching format for image processing courses. Fourth, scientific imaging pipelines that need raw pixel access without the overhead of a decompression library.

For every other use case, PNG (lossless, 5-20x smaller), JPEG (lossy, 12-30x smaller for photographs), or WebP (variable, 17-40x smaller) are objectively better choices. FileDex converts BMP to any of these formats entirely in the browser via the Canvas API — decode the uncompressed bitmap, render to canvas, and re-encode with the target format's compression. A 6 MB BMP screenshot typically converts to a 300 KB PNG in under one second.