BMP guide

Windows Bitmap (BMP): Row Padding, Headers, and File Size

A BMP row occupies a multiple of four bytes. Read the file and DIB headers, calculate that aligned stride, and check the signed height before converting a working copy.

File header14 bytes before the DIB header
Row storageEach scan line rounds up to a 4-byte boundary
Signed heightPositive is bottom-up; negative can be top-down
AI-generated editorial portrait representing Maya Chen, imgrove image workflow editor

About Maya Chen

Image Workflow Editor

Maya is the editorial pen name used by the imgrove team. Her portrait is AI-generated. The team publishes tested, source-based guides to image formats and browser workflows.

Read the two headers before trusting the extension

A Windows bitmap file starts with a 14-byte BITMAPFILEHEADER, followed by a DIB header such as BITMAPINFOHEADER. Microsoft documents the file header as the part that identifies the file, gives its byte size, and points to the first bitmap byte. [1] [3] The first two bytes normally spell BM for this common file form.

Treat the extension as a hint and the header as evidence. The file header's bfSize field declares a total byte count; bfOffBits gives the offset to pixel data. The first DWORD in the DIB header gives that header's size, which distinguishes the Windows header variants. [2] Width, height, bit depth, and compression then describe how to interpret the stored raster.

Calculate the 4-byte-aligned row stride

BMP stores each scan line on a 4-byte boundary. Calculate row stride in bytes as floor((width × bits per pixel + 31) ÷ 32) × 4. Padding belongs to storage, not to visible pixels. Microsoft's stride guidance explains that these extra bytes change the distance between rows while leaving the displayed image unchanged. [5]

For a 101 × 2 pixel, 24-bit BMP, one raw row needs 101 × 24 ÷ 8 = 303 bytes. The aligned stride is floor((101 × 24 + 31) ÷ 32) × 4 = 304 bytes. Two rows therefore need at least 608 pixel-array bytes, with one padding byte after each row. Width × height × three gives 606 bytes and misses that padding.

Use signed height to identify row order

For an uncompressed RGB BITMAPINFOHEADER, a positive height describes a bottom-up DIB: the first stored scan line belongs at the bottom of the displayed image. A negative height describes a top-down DIB whose first stored row appears at the top. [2] [4] Calculate the pixel-array length with the absolute height.

Keep the boundary precise. Older BITMAPCOREHEADER files and run-length-encoded bitmaps do not use the same top-down option, and Microsoft requires a positive height for compressed BITMAPINFOHEADER formats. [2] A header reader can report the sign; only a decoder that supports the exact variant should render the pixels.

Compare the pixel estimate with the declared file size

For an uncompressed BI_RGB or BI_BITFIELDS bitmap, aligned stride × absolute height gives a useful minimum pixel-array estimate. It does not give every file byte. The 14-byte file header, DIB header, optional channel masks, color table, profile data, and any gap before bfOffBits add storage around the pixels. [1] [4]

Compare three values: the actual file length, bfSize, and bfOffBits plus the calculated pixel-array bytes. A mismatch is a review signal, not an automatic verdict; compressed payloads and later header variants need format-specific handling. Keep reasonable parser bounds and open valuable files in software that supports their exact DIB header.

Inspect the BMP locally, then convert a working copy

Drop the file into the imgrove Image Size Checker. Its bounded BMP reader reports the BM signature, declared file size, pixel-data offset, DIB header size, stored width and signed height, row direction, bit depth, compression code, calculated stride, and minimum pixel-array bytes. The browser reads the file locally and can save a plain-text handoff report.

The check reads headers; it does not decode pixels, prove that every offset is valid, or certify the file. Keep the original BMP unchanged when a legacy workflow still needs it. Convert a copy to PNG for lossless everyday exchange, or to JPEG, WebP, or AVIF when a photographic delivery workflow accepts their quality trade-offs.

BMP fields to verify before conversion

FieldWhat it tells youReview rule
bfSizeTotal file bytes declared by the BMP headerCompare it with the actual file length
bfOffBitsByte offset where the pixel payload beginsConfirm it follows required headers, masks, and palette
DIB header sizeWhich family of bitmap fields followsDo not apply one variant's rules to every BMP
Signed heightStored height and, for supported RGB DIBs, row directionUse the absolute value in byte calculations
Bit depth and compressionBits per pixel and pixel encodingUse the stride estimate only where the encoding permits it

Use BMP when

  • A legacy Windows application explicitly requires the format
  • A test fixture needs simple, inspectable raster rows
  • The source must remain unchanged for an established workflow

Choose a delivery copy when

  • A website or email needs broadly efficient image delivery
  • A photo collection needs compact storage and transfer
  • The recipient does not support the exact DIB header variant
Image Dimensions vs File Size: Pixels, KB, and MB PNG: lossless pixels, transparency, and dependable screenshots TIFF for Archival Scans: Compression, Pages, and Header Checks
Image Size Checker JPG to PNG Converter WebP Converter

Check the BMP header before conversion

Inspect a .bmp locally for signed height, row direction, bit depth, compression, 4-byte row stride, pixel offset, and declared file size. Keep the source, download the text report, and send feedback if a real-world header needs clearer handling.

Try Image Size Checker

Technical references