BMP (Windows Bitmap) Image Format — Complete Guide
What Is BMP?
BMP (Bitmap) is a raster graphics file format native to Microsoft Windows, originally introduced with Windows 1.0 in 1985. BMP stores pixel data in a straightforward, largely uncompressed format called the Device Independent Bitmap (DIB), making it one of the simplest image formats to parse and one of the most universally readable by Windows software. While largely superseded by PNG, JPEG, and WebP for most purposes, BMP remains relevant in scenarios requiring raw pixel access, Windows API integration, and professional display calibration workflows.
File Structure
A BMP file consists of four main sections:
1. File Header (14 bytes)
Signature : 2 bytes ('BM' — identifies the file as BMP)
File size : 4 bytes (total file size in bytes)
Reserved : 4 bytes (application-specific; typically 0)
Data offset : 4 bytes (byte offset from file start to pixel data)
2. DIB Header (Variable — most common: BITMAPINFOHEADER, 40 bytes)
Header size : 4 bytes (40 for BITMAPINFOHEADER)
Width : 4 bytes (signed; negative = top-down row order)
Height : 4 bytes (signed; positive = bottom-up, negative = top-down)
Planes : 2 bytes (always 1)
Bit count : 2 bytes (bits per pixel: 1, 4, 8, 16, 24, 32)
Compression : 4 bytes (0=none, 1=RLE8, 2=RLE4, 3=bitfields, etc.)
Image size : 4 bytes (size of raw image data; 0 if uncompressed)
X pixels/m : 4 bytes (horizontal print resolution)
Y pixels/m : 4 bytes (vertical print resolution)
Colors used : 4 bytes (palette size; 0 = default for bit depth)
Important : 4 bytes (important colour count; usually 0)
3. Colour Table (Optional)
For 1-bit, 4-bit, and 8-bit BMP files, a colour palette (colour table) defines up to 256 RGBQUAD entries. Each entry is 4 bytes: Blue, Green, Red, Reserved. True-colour (24-bit) and RGBA (32-bit) BMPs have no colour table.
4. Pixel Data
Raw pixel values, stored left-to-right and (by default) bottom-to-top. Rows are padded to 4-byte boundaries. For a 24-bit BMP at 100 × 100 px: each row is 300 bytes (100 × 3) + 0 bytes padding (already divisible by 4) = 30,000 bytes total pixel data.
Colour Depth Options
| Bit Depth | Colours | Description |
|---|---|---|
| 1-bit | 2 | Monochrome; black/white or two custom palette colours |
| 4-bit | 16 | 16-colour indexed; uses colour table |
| 8-bit | 256 | 256-colour indexed; uses colour table; optional RLE compression |
| 16-bit | 32 768 / 65 536 | High colour; 5-5-5 (555) or 5-6-5 (565) RGB encoding |
| 24-bit | 16.7 million | True colour; 8 bits per RGB channel; most common BMP |
| 32-bit | 16.7 million + alpha | RGBA; 8 bits per channel + 8-bit alpha (or unused byte) |
24-bit vs 32-bit BMP
24-bit BMP has no alpha channel — every pixel is fully opaque. 32-bit BMP in theory has 8 bits for alpha, but the BITMAPINFOHEADER header does not formally define this behaviour; the 4th byte per pixel is "reserved". Some applications interpret it as alpha (yielding ARGB or BGRA pixels), others ignore it. The BITMAPV4HEADER and BITMAPV5HEADER extensions formally define the alpha channel mask, used by modern Windows API calls.
Compression in BMP
No Compression (Most Common)
The majority of BMP files use BI_RGB compression code (value 0) — meaning no compression at all. Pixel data is stored as-is, making BMP files proportional to their dimensions:
File size ≈ 54 bytes (headers) + (width × height × bytes_per_pixel)
A 1920 × 1080 24-bit BMP = 54 + (1920 × 1080 × 3) = ~6.22 MB
RLE (Run-Length Encoding)
BI_RLE8 and BI_RLE4 provide run-length compression for 8-bit and 4-bit BMPs respectively. RLE encodes consecutive identical pixels efficiently. Example: "20 pixels of colour 5" becomes 2 bytes instead of 20. RLE works well for graphics with large flat-colour regions (logos, pixel art) but poorly for photographs.
Bitfield Masks
BI_BITFIELDS allows custom bit masks for 16-bit and 32-bit BMPs, defining which bits encode Red, Green, Blue, and Alpha channels. Used when non-standard channel layouts (e.g., RGBA rather than the default BGRA) are needed.
Bottom-Up vs. Top-Down Row Order
BMP stores rows bottom-to-top by default (the first pixel data byte describes the bottom-left pixel). This is a historical artefact from early display technology. A negative height value in the DIB header indicates top-down storage (first byte = top-left pixel), which simplifies direct rendering on modern display hardware. Most BMP readers handle both transparently.
Advantages of BMP
- Universal Windows compatibility — readable by every Windows application, Windows API, and GDI/GDI+ without external libraries
- Lossless and uncompressed — pixel data is stored exactly as-is; no quality loss, no artefacts
- Simple structure — trivial to parse; useful for low-level programming and hardware interfaces
- No patent concerns — completely open format with no licensing restrictions
- Direct memory mapping — the pixel data layout maps directly to Windows GDI device contexts; no decoding required for rendering
- Support for all colour depths — from 1-bit monochrome to 32-bit RGBA
Disadvantages of BMP
- Enormous file sizes — 24-bit BMP at 1920 × 1080 = 6.22 MB; equivalent PNG = 0.8–2 MB; equivalent JPEG = 0.1–0.5 MB
- No metadata support — BMP has no standard way to embed EXIF, ICC profiles, or copyright information; the reserved bytes are application-specific and not standardised
- Limited colour management — no ICC profile embedding in the base format; extended headers (BITMAPV5HEADER) add colour space data but are rarely used
- No animation — static images only
- No web use — browsers technically support BMP but it is never used in web publishing due to file size
- Monochrome only for 1-bit — no greyscale support in standard headers (8-bit indexed can simulate greyscale with appropriate palette)
BMP in Windows Programming
BMP's primary relevance today is in Windows system programming:
- GDI (Graphics Device Interface) — Windows rendering engine works natively with DIB structures; BMP headers are the raw format of GDI bitmaps
- Resource files (.rc) — Windows application icons, cursors, and bitmap resources are stored as BMP data inside .exe/.dll resource sections
- Clipboard — Windows clipboard uses DIB format internally; applications exchange images via clipboard in BMP-compatible formats
- Screen captures — the classic Windows
PrintScreenputs a BMP-format image on the clipboard before any application recompresses it - Hardware interfacing — some display drivers and embedded systems prefer simple BMP structures for direct framebuffer access
Display Calibration and Scientific Use
Despite its age, BMP is valued in specific technical contexts:
- Monitor calibration — calibration software sends BMP test patterns directly to GDI for pixel-accurate rendering without JPEG artefacts
- Medical imaging — legacy PACS (Picture Archiving and Communication Systems) software uses BMP for temporary image storage during processing
- Computer vision research — uncompressed pixel data eliminates compression artefacts that could corrupt algorithm results; BMP provides a clean input baseline
BMP vs. PNG: When to Use Each
| Criterion | BMP | PNG |
|---|---|---|
| File size | Large (uncompressed) | Small (DEFLATE lossless) |
| Lossless quality | Yes | Yes |
| Alpha transparency | Partial (v4/v5 headers only) | Full native support |
| Metadata (EXIF/ICC) | No | Yes |
| Web publishing | No | Yes |
| Windows API compatibility | Maximum | Good (via codec) |
| Simplicity of parsing | Maximum | Moderate |
Choose BMP for Windows GDI programming, clipboard operations, calibration targets, and any scenario requiring zero-codec raw pixel access. Choose PNG for virtually everything else — web, sharing, archive — where file size and metadata matter.
Converting BMP Files
Converting BMP to PNG is straightforward and lossless: both are lossless formats, and PNG's DEFLATE compression typically reduces a 6 MB BMP to under 2 MB with zero quality difference. BMP to JPEG reduces file size by 95 % or more with minor quality trade-offs at typical JPEG quality settings (85–95).