What is a BMP file?

BMP is a binary format, meaningful only to a program that knows it. It stores a grid of pixels, so enlarging it past its own resolution softens it. It is used for moving data between programs.

The extension is .bmp, and the full name is Windows Bitmap. Both matter less than what the file can hold, which is what the rest of this page is about.

Microsoft published it in 1987.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is written down and implementable, though the vendor decides what the next version looks like. In practice that is enough for the file to keep opening; it is not enough to be sure of it.

It still opens everywhere and is still written by older tools, but nothing new is being built around it. Convert what you mean to keep, and do not choose it for something starting today.

BMP stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

BMP has nowhere to record transparency. Anything transparent in the source is filled with a solid colour on the way in — white, unless something chooses otherwise.

Up to 8 bits per channel. It can work in RGB and an indexed palette.

Eight bits per channel is what a screen shows and what nearly every delivery format carries.

Microsoft Paint, GIMP and IrfanView read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

Every current browser reads it.

That makes it a safe thing to put on a page or attach to a message without wondering what the other end has installed.

BMP is meant to be handed over rather than worked in. Editing one is possible and rarely pleasant; the sane approach is to change the source and export again.

The recurring complaints: the files are large for what they contain.

None of these is a reason to avoid the format. They are the things worth knowing before you are surprised by one, which is a different claim and a more useful one.

A BMP stores every pixel as a literal colour value, in order, with nothing clever applied. That makes the file size predictable to the byte: width times height times bytes per pixel, plus a small header. A 1920 by 1080 image at 24 bits per pixel is about 6.2 megabytes regardless of whether it shows a photograph or a plain white rectangle.

That single property explains every complaint about the format. A screenshot that would be 200 kilobytes as PNG is several megabytes as BMP. A scanned page is tens of megabytes. Nothing has gone wrong — the format simply never had a mechanism for making anything smaller, which in 1990 was a reasonable trade for being trivial to read.

A BMP conventionally stores its rows from the bottom of the image to the top. The reason is historical — it matched the coordinate system of the graphics hardware the format was designed around — and it is why a BMP written by naive code sometimes appears vertically mirrored.

The header can declare the opposite order using a negative height, and some software writes it that way. Both are valid, which is a fair summary of the format: simple enough to implement in an afternoon, with enough variation that implementations disagree at the edges.

The original 1990 header is 40 bytes and describes dimensions, colour depth and little else. Later versions extend it to 108 and 124 bytes to add colour space information and an alpha channel, and a few tools write a version that predates all of them.

Most readers handle the common cases and some do not handle the extended ones. If a BMP opens in one program and is refused by another, a header version mismatch is the usual explanation rather than damage — and it is why a file produced by a scientific instrument sometimes defeats ordinary image software.

The 32-bit variants have room for an alpha channel and the extended headers can describe it properly. In practice support is unreliable enough that transparency in a BMP cannot be depended on: many readers ignore the fourth byte entirely and render the image opaque.

So if an image needs a transparent background, BMP is the wrong container for it and PNG is the right one. Converting a BMP that claims transparency to PNG is also the reliable way to find out whether the transparency was ever really there.

BMP does define two run-length encodings, for 4-bit and 8-bit images, which compress runs of identical pixels. They work and are almost never used, because they apply only to low colour depths and because by the time compression mattered, PNG existed and was better at it in every case.

A BMP you encounter is therefore almost certainly uncompressed. Treating that as a safe assumption is reasonable; it is also why converting one to PNG so reliably produces a dramatic size reduction with nothing lost.

Scanners and scanning software, particularly older or industrial ones. Medical and laboratory instruments, which favour formats that are trivial to write and impossible to misinterpret. Windows utilities and screen-capture tools of a certain age. Embedded systems and machine vision, where a decoder is a liability and raw pixel data is a feature.

And software written in the 1990s that has never had a reason to change. The common thread is a preference for simplicity over size, which for a device writing to a local disk is a defensible choice and for a file that has to be emailed is not.

The Windows clipboard uses a BMP-derived structure for images, so copying a picture between applications passes something very close to this format. Icon files contain BMP data. Some parts of the interface still use it internally.

That is why the format has not disappeared and will not: it is not really a file format any more so much as the way Windows represents an uncompressed image, with a file wrapper available when one is needed.

PNG, in nearly every case. It is lossless, so every pixel arrives exactly as it was, and it compresses — a screenshot or a diagram commonly lands at a small fraction of the BMP size with no visible change whatsoever. There is no argument against it beyond software older than 1996.

JPG only when the image is a photograph and size matters more than exactness, since it will discard detail to get smaller. For a scanned document, a screenshot, a diagram or line art, PNG is strictly better and JPG will make the text edges worse.

The reason to convert a BMP is almost always that it is too large to move, which makes uploading it to a converter a poor way to solve the problem — the upload is the slow part, and many services impose a size limit that a large uncompressed scan exceeds.

Converting in the browser removes the upload: nothing is transmitted, and a folder of scans converts without a queue or a daily allowance being spent. There is still a ceiling, and on this format it is worth knowing where it sits — the free limit is 100 MB per file, 100 files at a time, and at three bytes per pixel a 24-bit BMP reaches 100 MB at roughly 35 megapixels, which a 600 dpi colour scan of an A4 page sits just under. Given that the devices producing BMP are frequently scanners and medical instruments, the file not leaving the machine is worth as much as the speed.