The BMP format

Where it came from

BMP arrived with Windows 1.0 in 1986, and the full name explains the design: the device-independent bitmap. The file was meant to hold pixels in a layout the display hardware could accept with as little work as possible, so drawing one was closer to a memory copy than to a decode. On a machine where the processor was the scarce resource, spending cycles unpacking a compressed image to save disk space was the wrong way round.

The structure has barely changed since. A short file header, a header describing the pixel layout, then the rows of pixels themselves — stored bottom-up, and padded so every row starts on a four-byte boundary. Both of those details have caught out every programmer who has ever written a BMP parser for the first time.

Why the files are so big

There is no mystery in it. A 4000 × 3000 photograph at 24 bits per pixel occupies 4000 × 3000 × 3 bytes, which is around 36 MB, and it occupies exactly that whether the image is a landscape or a flat grey square. The format does define a run-length encoding for its 4- and 8-bit colour-mapped modes, but almost nothing writes it and it does nothing useful for photographs.

Compare that with the alternatives holding the same picture: a JPEG at a sensible quality lands somewhere around 2–4 MB, a PNG of a screenshot often a tenth of the bitmap, a WebP smaller again. That gap is the whole reason people arrive here with a BMP.

What it is still good for

Simplicity, mainly. A working BMP decoder fits in a page of code with no library behind it, which is why the format survives in firmware, embedded interfaces, test fixtures and Windows resource files — places where a dependency costs more than the bytes do. It is also a reasonable scratch format when two programs on the same machine are passing pixels back and forth and the disk is free.

The common variants carry no metadata at all: no EXIF, no GPS coordinates, no capture date. Occasionally that is a feature rather than an omission.

Why nothing here saves one

There is no version of “make this image smaller” that ends in an uncompressed bitmap, so BMP is not one of the five formats this tool writes. Reading is a different question and costs nothing — browsers decode BMP themselves, so no extra code is downloaded to open one.

Inbound is where BMP is interesting. It is the format that produces the largest reductions this tool ever reports, and the reduction is not a compromise: converting to PNG keeps every pixel exactly and still throws away most of the file.

What to convert it to

PNG is the default. Lossless, the same pixels, transparency preserved where the source had it, and typically a fraction of the size. If you do not have a specific reason to choose otherwise, choose this.

JPG if the image is a photograph and the file needs to be small. It is lossy, so it is the wrong answer for line art, screenshots or anything with hard edges and flat colour.

WebP if it is going on a website. Smaller than PNG for graphics and smaller than JPEG for photographs, and every current browser displays it.