BMP / DIB Inspector

Because bottom-up is the default. A BMP stores the last row of the image first unless biHeight is negative, in which case the rows run top-down and the real height is the absolute value of the field. Almost every image format stores rows top-down, so a decoder written from habit rather than from the spec produces a vertically mirrored picture on the common case and a correct one on the rare case. This page reports the stored value and the sign separately, so you can see which kind of file you have before you go looking through your own code.

Nothing, usually — it is slack that a writer left behind, and it is entirely legal because the pixel array is located by bfOffBits in the file header and not by adding up the sizes of everything before it. Some writers align the pixel array to a disk sector, some reserve room for a palette they never filled in, and some simply leave the space a previous edit vacated. A reader that computes the offset itself instead of trusting bfOffBits will start reading a few bytes early or late and produce a diagonally skewed image, which is the classic symptom.

By the letter of the specification, not in a plain BI_RGB file: the byte is documented as unused padding, and the format only gains a real alpha channel through an alpha mask under BI_BITFIELDS or BI_ALPHABITFIELDS, or through a V4 or V5 header that names one. In practice most writers store alpha there anyway, and most readers ignore it — Pillow, for one, reads such a file back as plain RGB. The result is a file that looks correct in one program and either black or invisible in another, and there is no way to settle it from the bytes alone. This page tells you which of the two cases you have rather than guessing.

Only from the channel masks. Both pack a pixel into two bytes, both declare 16 bits per pixel, and nothing else in the header distinguishes them; the red, green and blue masks say which bits belong to which channel, and the green mask is five bits wide in one and six in the other. A 16-bit BI_RGB file with no mask block at all is 5-5-5 by default. This page decodes each mask into the position of its lowest set bit and how many contiguous bits it covers, which is the form you actually need when writing a shift-and-scale in a decoder.

They are simple run-length encodings for 8-bit and 4-bit paletted images: a byte pair is either a run of one colour or an escape, and the escapes cover end-of-line, end-of-bitmap and a delta that jumps the cursor by an x and a y offset and leaves everything it skipped undefined. They were meant for the era when a bitmap on a floppy was worth compressing, and they still turn up in old Windows resources and in files produced by legacy tooling. Both are decoded here, and the number of delta escapes and how many pixels they left unwritten are reported, since those pixels are the part where readers visibly differ.

No. The file is read with the browser's File API and parsed by JavaScript in this page, and the previews are drawn on a canvas in the same tab. There is no server-side component to send anything to. That matters for this kind of tool more than most: a bitmap you are inspecting is often a screenshot, a scan or an asset from something you are not free to hand to a web service. You can disconnect from the network after the page has loaded and everything on it still works.