BMP Format: Windows Bitmap Specs & Use Cases

Origin and role

BMP (Bitmap, sometimes "DIB" for Device-Independent Bitmap) is Microsoft's native raster image format, introduced with Windows 1.0 in 1985. The design intent was straightforward: a simple, uncompressed format that any Windows application could read and write without external dependencies.

For its design era, that simplicity was a virtue. Reading or writing a BMP required nothing more than reading a header and copying pixel data — no Huffman decoding, no DCT, no compression algorithms. On the hardware of the time, this was the right trade-off.

BMP's role today is residual. The format is universally readable but practically never the right choice for serving, sharing, or storing modern image content. It survives in legacy Windows workflows, in some embedded systems, and as an intermediate format in screen capture and clipboard operations.

File structure

A BMP file consists of:

File header (14 bytes) — magic bytes ("BM"), file size, offset to pixel data.
Info header (typically 40 bytes, can be longer) — width, height, bit depth, compression method, image size, resolution.
Optional colour table — required for indexed-colour images (1, 4, 8 bits per pixel).
Pixel data — the actual image content, padded to 4-byte boundaries per row.

The format has gone through several header revisions adding optional capabilities (alpha channel, ICC colour profile, embedded JPEG/PNG, large addresses for files over 2 GB). Most BMP files in the wild use the original 40-byte header without extensions.

Compression options

Despite being known as "uncompressed", BMP supports several compression methods:

BI_RGB (0) — no compression. Default and most common.
BI_RLE8 — run-length encoding for 8-bit images.
BI_RLE4 — run-length encoding for 4-bit images.
BI_BITFIELDS — uncompressed, with non-standard channel masks.
BI_JPEG, BI_PNG — embeds JPEG or PNG data inside the BMP container. Rarely used; defeats the purpose of BMP.

In practice, almost all BMP files in use are uncompressed (BI_RGB). The RLE variants exist but are obscure and supported inconsistently. The embedded-JPEG and embedded-PNG variants are nominal — if you need JPEG or PNG, use them directly rather than wrapping in BMP.

File size

Uncompressed BMP files are large. The size formula is roughly:

bytes ≈ width × height × (bit_depth / 8) + headers

For a 1920×1080 24-bit colour image, that's approximately 6.2 MB — versus 100–300 KB as a JPEG of the same content, 50–200 KB as WebP. The size difference is not subtle.

Why BMP persists

Given how much larger BMP files are than any modern alternative, the format's persistence requires explanation. The main reasons:

Clipboard interoperability on Windows. When you copy an image in any Windows application, it's typically stored on the clipboard as a DIB (the in-memory equivalent of BMP). Paste targets that don't understand richer formats fall back to DIB.
Embedded systems and microcontrollers. Devices with limited CPU often cannot decode JPEG or PNG. BMP requires no decoding — just memcpy.
Programming exercises and assignments. "Read a BMP file" is the canonical introductory image-processing exercise because the format is trivially parseable.
Legacy Windows applications. Old software that hasn't been updated may only read BMP.
Some image-processing pipelines use BMP as an intermediate format because it's lossless and trivially encoded.

Bit depth options

BMP supports:

1-bit — black and white. Uncommon today.
4-bit — indexed colour, 16-colour palette. Mostly historical.
8-bit — indexed colour, 256-colour palette. Equivalent to GIF colour fidelity.
16-bit — direct colour with 5-6-5 or 5-5-5 channel allocation. Some embedded systems use this.
24-bit — direct colour, full 8 bits per RGB channel. Most common modern BMP.
32-bit — direct colour with alpha channel (typically; some 32-bit BMPs ignore the alpha bits).

24-bit is the dominant case for modern BMP usage outside specific embedded contexts.

Alpha transparency

BMP nominally supports alpha through the 32-bit format, but support is inconsistent:

Many image viewers treat 32-bit BMP as 24-bit and ignore the alpha bits.
Even applications that recognise alpha sometimes interpret it incorrectly (premultiplied vs straight, transparency vs translucency).
The original BMP specification didn't include alpha; it was added through informal convention.

For reliable transparency, use PNG or WebP instead. BMP's alpha is too unreliable for production use.

Browser support

Most modern browsers do render BMP — Chrome, Firefox, Safari, Edge all support it natively. However, the format is so wasteful that no production website serves BMP intentionally. The browser support exists for completeness and for handling files that arrive from clipboard paste or download.

For web delivery, BMP should always be converted to a real web format (WebP, AVIF, JPEG, PNG) before serving.

Modern relevance

BMP matters for:

Windows clipboard operations — the lingua franca of OS-level image transfer on Windows.
Embedded systems and firmware — devices with no compression decoder.
Microcontroller graphics — simple displays driven by parsed BMP files.
Legacy Windows software — applications that pre-date PNG/WebP support.
Programming education — introductory image-processing exercises.
Some scanning and OCR pipelines — intermediate format between scanner driver and OCR engine.

BMP does not matter for:

Web delivery — always too large; convert to WebP or JPEG first.
Email attachments — file sizes alienate recipients on metered connections.
Cloud storage — wastes storage cost compared to JPEG, PNG, or WebP.
Modern Windows applications — should use PNG or WebP internally.
Any cross-platform context — friction with macOS and Linux clipboard, no benefit over PNG.

When to use BMP today

Use BMP only when:

You're targeting an embedded device or microcontroller that explicitly requires it.
You're producing files for legacy Windows software with no other supported format.
You're working through a teaching exercise.
You're using it as an in-memory clipboard format (this happens automatically; you don't usually choose it explicitly).

For every other case, prefer PNG (if you want lossless), WebP (if you want lossless or lossy with small files), JPEG (if you want maximum compatibility for photographic content), or any other modern format.

Conversion guidance

Converting BMP to a modern format is almost always pure upside. The pipeline:

Decode the BMP to pixel data (any image library does this in milliseconds).
Encode to the target format with appropriate parameters.

# BMP to WebP with ImageMagick (lossy, typical web use)
convert input.bmp -quality 80 -define webp:method=6 output.webp

# BMP to PNG (lossless, when transparency or fidelity matters)
convert input.bmp output.png

# BMP to JPEG (universal compatibility)
convert input.bmp -quality 85 output.jpg

Typical reductions: a 24-bit BMP at 1920×1080 (6.2 MB) drops to roughly 200 KB as WebP at q=80 — a 30× reduction with no visible quality difference for typical photographic content.

For Sharp-based Node pipelines:

import sharp from "sharp";

await sharp("input.bmp")
  .webp({ quality: 80, effort: 6 })
  .toFile("output.webp");

Common scenarios

A user uploads a BMP to your site. Your pipeline should accept BMP input and convert it to a web-friendly format (WebP or JPEG) before storage. Don't store user-submitted BMPs directly; they'll be slow to serve and consume excessive storage.

A clipboard paste lands as a BMP. This is normal Windows behaviour. Web applications that accept clipboard images should handle BMP gracefully via the same conversion pipeline used for uploads.

A legacy export from old software is a BMP. Convert once, archive the original if compliance demands it, serve the converted version going forward.

An embedded device needs an image. BMP may be the right choice. Check what compression methods the device's decoder supports.