About

BMP (Bitmap) files use a rigid binary structure defined by Microsoft. A corrupt or malformed header causes silent rendering failures across applications. This tool performs byte-level inspection of the 14-byte BITMAPFILEHEADER and the subsequent DIB header (sizes 12 to 124 bytes depending on version). It validates the magic signature (0x42 0x4D), cross-references the declared file size against actual byte count, identifies the compression method (BI_RGB, BI_RLE8, BI_BITFIELDS, etc.), and verifies pixel data integrity by computing expected row stride with 4-byte padding alignment. Mismatched values indicate corruption or non-standard encoding that may fail in strict parsers.

The tool handles all six DIB header versions from the legacy 12-byte OS/2 BITMAPCOREHEADER through the modern 124-byte BITMAPV5HEADER with ICC color profile support. Resolution values stored as pixels per meter are converted to DPI for practical use. Limitation: RLE-compressed pixel streams are not decompressed for per-pixel verification. The integrity check assumes uncompressed or BITFIELDS data layout.

Formulas

The BMP file begins with a 2-byte magic number followed by structured binary headers. Pixel data rows are padded to align on 4-byte boundaries.

Row Stride = floor(bpp × width + 3132) × 4

Where bpp = bits per pixel, width = image width in pixels. The result is in bytes.

Expected Pixel Data = Row Stride × |height|

Absolute value of height is used because negative height indicates top-down row order (origin at top-left) versus the default bottom-up order. The file integrity check compares this computed pixel data size against the actual bytes available after the pixel data offset.

DPI = round(ppm × 0.0254)

Where ppm = pixels per meter (stored in header as a 32-bit signed integer). Multiply by 0.0254 to convert to dots per inch.

Color Table Entries = 2^bpp if bpp ≤ 8 and clrUsed = 0

When clrUsed is non-zero, that value specifies the actual number of palette entries. Each entry is 4 bytes (BGRA) in BITMAPINFOHEADER and later, or 3 bytes (BGR) in the legacy BITMAPCOREHEADER.

Reference Data

DIB Header	Size (bytes)	Introduced	Max Bit Depth	Compression Support	Color Space	Notes
BITMAPCOREHEADER	12	OS/2 1.x	24	None	None	Legacy; uses 16-bit width/height
BITMAPINFOHEADER	40	Windows 3.0	32	BI_RGB, BI_RLE8, BI_RLE4, BI_BITFIELDS	None	Most common version in the wild
BITMAPV2INFOHEADER	52	Undocumented	32	BI_BITFIELDS	None	Adds RGB bit masks
BITMAPV3INFOHEADER	56	Undocumented	32	BI_ALPHABITFIELDS	None	Adds alpha channel mask
BITMAPV4HEADER	108	Windows 95 / NT 4.0	32	All + BI_JPEG, BI_PNG	LCS_CALIBRATED_RGB	Adds color space endpoints and gamma
BITMAPV5HEADER	124	Windows 98 / 2000	32	All	LCS_sRGB, PROFILE_LINKED, PROFILE_EMBEDDED	Full ICC profile support
Compression Methods
BI_RGB	0		No compression (raw pixels)
BI_RLE8	1		Run-length encoding for 8-bit images
BI_RLE4	2		Run-length encoding for 4-bit images
BI_BITFIELDS	3		Pixel format defined by bitmasks (16/32-bit)
BI_JPEG	4		JPEG-compressed pixel data (V4+)
BI_PNG	5		PNG-compressed pixel data (V4+)
BI_ALPHABITFIELDS	6		RGBA bitmasks (V3+, CE only)
Bit Depth Reference
1-bit	Monochrome		2 colors, palette required
4-bit	16 colors		Palette required, supports BI_RLE4
8-bit	256 colors		Palette required, supports BI_RLE8
16-bit	High color		Default: 5-5-5 + 1 unused, or BITFIELDS
24-bit	True color		BGR byte order, no alpha, most common
32-bit	True color + alpha		BGRA byte order or BITFIELDS-defined

Frequently Asked Questions

The signature bytes (0x42 0x4D) only confirm the file identifies as BMP. Pixel data integrity depends on the relationship between declared dimensions, bit depth, and actual file size. Common causes: the file was truncated during transfer (missing tail bytes), the pixel data offset points past the end of the file, or the declared image dimensions produce a row stride that exceeds available data. Check the "Expected Pixel Data" value against "Available Pixel Data" in the results. A mismatch indicates corruption or an incomplete download.

A negative height indicates top-down row order. Standard BMP stores rows bottom-up (the first row of pixel data is the bottom scanline of the image). When height is negative, rows are stored top-down like most other image formats. This is only valid with BI_RGB and BI_BITFIELDS compression. RLE-compressed BMPs must use positive (bottom-up) height. The checker reports both the raw signed value and the orientation interpretation.

Each pixel row is padded to the nearest 4-byte boundary. For a 24-bit image that is 1 pixel wide, each row uses 3 bytes of pixel data plus 1 byte of padding = 4 bytes total. For 10 pixels wide: 30 bytes of data + 2 bytes padding = 32 bytes. This padding is critical for calculating expected file size. If you manually construct BMP data and omit padding, parsers will misalign subsequent rows, producing a characteristic diagonal skew artifact.

Yes, but only in specific configurations. 32-bit BMP with BITMAPV3INFOHEADER or later can store an alpha channel via BI_BITFIELDS or BI_ALPHABITFIELDS compression, where the fourth bitmask defines the alpha bits. BITMAPV4HEADER and V5HEADER explicitly support alpha masks. However, many applications ignore the alpha channel in BMP files. The 32-bit BITMAPINFOHEADER (header size 40) with BI_RGB compression stores 8 unused bits per pixel - some software interprets these as alpha, others do not. This tool reports the alpha mask value when present.

Microsoft never officially published specifications for the 52-byte (V2) and 56-byte (V3) header variants. They were used internally by Adobe products and some Windows components. The V2 header adds explicit RGB bitmasks (12 extra bytes over the 40-byte INFOHEADER), and V3 adds an alpha bitmask (4 more bytes). These are identified solely by their header size field. Files using these headers are valid but may not render correctly in all applications. The standard progression is from the 40-byte BITMAPINFOHEADER directly to the 108-byte BITMAPV4HEADER.

Width and height are stored as 32-bit signed integers, giving a theoretical maximum of 2,147,483,647 pixels per axis. Practically, file size becomes the constraint. A 32-bit uncompressed BMP at 100,000 × 100,000 pixels would require approximately 37.25 GB of pixel data alone. Most applications impose their own limits well below the format maximum. The checker validates that declared dimensions produce a reasonable pixel data size relative to the actual file.