Add your file
Choose or drop a .bmp file. You can paste the contents instead.
Choose a .bmp file and the inspector lays out its structure field by field. The 14-byte file header shows the BM signature, the declared file size next to the real one, both reserved words and the pixel data offset. The DIB header variant is identified strictly from its size (12, 16, 40, 52, 56, 64, 108 or 124 bytes), and you get width, the signed stored height, the absolute height, a top-down flag, planes, bits per pixel and the compression value with its name. For uncompressed and bitfield images it computes the padded row stride and the expected raw pixel size, then compares that with the bytes actually present after the pixel offset as one byte-gap figure; shortfalls, trailing bytes and unaccounted bytes before the pixels are reported with counts and offsets. Indexed images get a palette table, bitfield images get their masks read from the right location, and V4/V5 headers show colour space type, endpoints and gamma as raw fixed-point integers plus converted values, rendering intent and any linked profile path as inert text. Everything can be downloaded as a JSON report.
or drop a file here
Choose or drop a .bmp file. You can paste the contents instead.
The file is read and parsed in this browser — nothing is uploaded.
Look over what came back, then copy it, download it, or move on.
Want to know how files are handled? Read the privacy notice →
Pick a .bmp file with the file chooser and the page immediately lists its file header, DIB header and pixel layout without any install. Results are grouped into panels for the file header, DIB header, pixel layout, bitfield masks, colour space and palette, followed by the full JSON report you can download. Only files are accepted; pasting text asks you to choose a file instead.
No. The bitmap is read into your browser's memory and parsed there, so the file's bytes are not sent to any server while it is inspected. That also holds for a V5 header that names an external colour profile: the path is printed as text and no request is made for it.
Open this page in Safari, Chrome or Firefox on macOS, choose the file, and the bits-per-pixel value appears in the summary at the top. The DIB header panel beside it shows the compression method name, such as BI_RGB or BI_BITFIELDS, along with the plane count and colours-used field, which Preview does not expose.
On Windows 11 use Edge, Chrome or Firefox; on Android use any current mobile browser and pick the file from storage. Parsing runs on the device in both cases. On a narrow screen the palette and colour space tables scroll sideways, and downloading the JSON report is a convenient way to read long palettes later.
The error means the first two bytes are not the ASCII letters BM, which usually happens when another format was renamed with a .bmp extension. The bytes actually found are shown, so 89 50 points to a PNG and FF D8 to a JPEG. Files starting with BA (OS/2 bitmap arrays) or CI, CP, IC, PT (OS/2 icons and pointers) get their own unsupported messages instead.
It means fewer bytes follow the pixel offset than the size the inspector compares against, so the byte gap is negative by exactly that amount. For uncompressed (BI_RGB) and bitfield images that size is computed from width, height and bit depth: a 2×2 24-bit image has an 8-byte stride and 16 expected bytes, so a file 12 bytes short shows a byte gap of −12. For RLE, Huffman or embedded JPEG/PNG data the comparison uses the declared image size (biSizeImage) instead, and when that field is 0 no gap is computed. Truncated downloads are the usual cause, and the tool does not pad or repair anything.
The ceiling is 100,000,000 bytes per file and cannot be raised, and eight DIB header sizes are recognised: 12, 16, 40, 52, 56, 64, 108 and 124 bytes. Those are CORE, the 16-byte OS/2 header, INFO, V2, V3, OS/2 2.x, V4 and V5. Any other size is labelled unknown with its raw value rather than being forced into the nearest layout.
This inspector cannot tell you that: it reports header fields and never issues a safety, malware or authenticity verdict. What it can do is list structure worth a second look, such as unaccounted bytes between the palette and the pixels, unaccounted bytes after the pixel data, or an external profile path, without saying what those bytes are for. Treat unexpected attachments through your antivirus and normal security process.
A negative stored height is the BMP convention for pixel rows written from the top of the image down, not a corruption sign. The inspector shows the signed value and the absolute height side by side and sets the top-down flag. A height of 0 or −2147483648, or a width of 0 or less, is rejected as invalid dimensions.
Yes, 1-, 4- and 8-bit indexed bitmaps list every palette entry with its blue, green and red bytes plus a #RRGGBB hex code. CORE headers use 3-byte entries while newer headers use 4 bytes, so a reserved column appears only for those. When biClrUsed is 0 the count defaults to 2, 16 or 256 by bit depth.
BI_RGB stores raw pixels, BI_BITFIELDS stores raw pixels whose channels are defined by masks, and RLE packs runs of identical palette indexes. The inspector computes stride and expected size only for the first two kinds; for RLE it compares available bytes with the declared image size when one is set and flags that the run data was not expanded. A bit count that does not fit the method is also flagged.
No, there is no conversion and no preview because pixels are never decoded or rendered. The only export is a JSON file describing the headers, palette and byte layout, named after your bitmap. Use an image editor if you need the picture in another format.
No. A clean header report only says the fields are internally consistent with each other and with the file length; it cannot show who made the image or whether pixels were changed. Edited bitmaps are routinely re-saved with perfectly valid headers, so consistent structure is not evidence of origin.