Clean a BMP

So what does this actually do?

Two things worth doing rather than passing the file straight through:

• Data past the declared size. The file header records how long the file is. Bytes after that point are invisible to every decoder, which makes them a classic hiding place. We find them and remove them.
• An honest answer. If your BMP is clean, we tell you it is clean rather than inventing something to remove.

What we deliberately keep

• The DIB header and colour table, unmodified — a BMP decodes from these byte for byte, and there is no safe way to touch them without risking a corrupt image.
• Every pixel byte, copied exactly. BMP is uncompressed, so there is nothing to re-encode and nothing to lose.

Why BMP carries so little

BMP predates the idea of embedding metadata in an image file at all. The Windows bitmap storage format defines a file header, an info header describing dimensions and colour depth, an optional colour table, and then raw pixel data — nothing else. There's no reserved space for EXIF, no chunk system like PNG's, no extension mechanism like GIF's. Software that wants to attach metadata to a BMP has nowhere standard to put it, which is exactly why the only realistic hiding place is data appended after the pixel array ends, past what the file header declares as the file's length.

That also makes BMP a poor format to convert into if you're trying to strip metadata from something else — the metadata doesn't carry over because BMP can't hold it, but the conversion step itself (usually through an image editor) may re-encode the pixels, which this page's exact-copy approach avoids entirely by only ever touching bytes after the declared file size.

Why "the DIB header" isn't one fixed size

BMP has shipped with several different info-header versions since its introduction — the original 12-byte BITMAPCOREHEADER, the 40-byte BITMAPINFOHEADER most files use today, and newer variants running to 108 or 124 bytes that add colour-space fields. A tool that assumes a fixed header length reads the wrong offset for anything but the most common case. The file header carries its own declared offset to where pixel data begins, and that field — not an assumption about which header version is in use — is what determines where the header block genuinely ends and pixel data starts, colour table included when the file has one.

Cleaning something else?

BMP rarely carries anything worth removing. If you're actually working with photos, check JPG or PNG instead — both carry far more identifying data than a bitmap ever does.