Convert BMP to PNG

A BMP stores one pixel as three bytes and does nothing else with them. There is no compression stage, no prediction, no dictionary — the file is the pixel grid written out in order, bottom row first, each row padded to a multiple of four bytes, with a short header in front. That makes the size arithmetic rather than a property of the image: width times height times three, near enough.

So a 1920 by 1080 screen capture is 6.2 MB whether it shows a spreadsheet or a sunset, and a 4000 by 3000 image is 36 MB either way. Nothing in the picture can make it smaller, which is the one thing that separates BMP from every other raster format here. The 100 MB free ceiling on this page works out at about 33 megapixels of BMP — a 6,660 by 5,000 image — and that is a limit this conversion genuinely runs into.

PNG is lossless in the strict sense: compression means finding a shorter way to write the same numbers, not deciding which numbers matter. The decoder reconstructs the original grid exactly, so a BMP converted to PNG and back gives the bytes you started with.

Which is why this page has no quality slider and nothing to tune. There is no trade to make. The only variables are how long the encoder spends looking for redundancy and how many bytes it finds, and both of those are settled before you press anything. That also removes the question people carry over from JPEG — whether converting again later will degrade the image further. It will not: a PNG re-saved as a PNG is the same picture, and a PNG converted back to a bitmap is the same picture as well, however many times the trip is made.

The PNG here is written by the jSquash encoder and then run through oxipng at level 2, which is a second pass that rewrites the file with better filter choices. On a 960 by 640 photograph that pass took the output from 1,366 KB to 468 KB in 464 ms — two thirds gone. Level 3 costs 1,133 ms and saves nothing further, which is why 2 is the setting rather than the highest available.

The same 960 by 640 picture as a BMP is 1.84 MB, so the finished PNG is roughly a quarter of it. A photograph is the worst case: flat material compresses far harder, because PNG filtering and the deflate stage behind it are built for exactly the runs of repeated values that screenshots, diagrams and line art are made of. That is also the material Windows tools most often hand you as a BMP, so the typical result on this page is considerably better than the photographic figure suggests. What no one can do is quote you a ratio in advance — that is the whole difference between a format whose size is arithmetic and one whose size is a property of the picture.

Microsoft Paint, IrfanView, scanner and capture utilities, industrial and laboratory software, and a long tail of programs written when Windows had one obvious bitmap format. BMP dates from 1987, the registry marks it legacy, and it survives because Windows still writes it and some software still reads nothing else.

Which means almost nobody chooses a BMP. It arrives — from a scanner driver, from a camera on a test rig, from an export dialogue with a single option in it — and converting it is the first thing anyone does. If the file is going anywhere that has an opinion about size, PNG is the format it should have been in from the start. The registry lists Microsoft Paint, GIMP and IrfanView as the software that reads it and interchange as its use, and that pair of facts is the whole story: BMP is what one program hands another on the same machine, and it stops making sense the moment the file has to travel.

BMP can hold an alpha channel; the 32-bit variants do, and PNG holds one too. Where the transparency exists it survives the conversion intact, which makes this a rare direction where nothing has to be flattened and no background colour has to be chosen.

Most BMP files do not have one. Twenty-four bits per pixel is the common case and there is no room for alpha in it, so what you will usually get is an opaque PNG of an opaque source. If the goal was to add transparency — to cut a logo out of the white rectangle it was saved on — that is an editing job, and no format conversion performs it. Nothing in the file records which of the white pixels were meant to be background and which were part of the drawing, so there is no rule a converter could apply that would not be a guess about somebody’s artwork.

BMP has a paletted mode: eight bits per pixel indexing a table of up to 256 colours, which cut the file by two thirds at a time when that mattered a great deal. Files from older tooling are often written this way.

The decode path here does not preserve that structure. The browser expands the palette and hands over full RGBA values, so the palette itself does not survive as a palette — the pixels do, exactly, but the compact indexed representation is rebuilt from scratch by the PNG encoder rather than carried across. The result is still a fraction of the BMP, and it is worth knowing if you specifically needed an indexed file at the other end.

The registry records no metadata containers for BMP at all: no EXIF, no XMP, no IPTC, no embedded colour profile. PNG can carry EXIF, XMP and an ICC profile, and there is simply nothing in the source to put in them.

The pipeline reinforces that. The decode hands over a grid of RGBA values and the encoder receives that grid and nothing else, so a BMP from a scanner or a screen capture becomes a PNG with no timestamp, no device name and no coordinates — not because anything was stripped out, but because none of it was ever there. The one consequence worth noting is colour: with no embedded profile in the source, the PNG will be read as sRGB by everything that opens it, which is right for a screen capture and worth checking if the bitmap came out of a colour-managed instrument.

BMP is one of the few formats here that the browser reads by itself, alongside GIF and ICO. There is no WebAssembly codec to fetch and compile before anything can happen, which is why this conversion starts instantly where a HEIC or a TIFF has to load a library first — TIFF being the format no browser ever adopted, and the reason this site carries its own implementation of it.

It has one consequence worth knowing. The decoder is the browser’s, so what counts as a readable BMP is the browser’s definition rather than the specification’s, and the format accumulated a long tail of variants over nearly forty years. If a file written by something unusual will not open, the failure is a readable sentence rather than a stack trace, and the practical answer is to re-save it from IrfanView or GIMP, both of which read more of that tail than any browser does.

Drop the whole folder. Each file is decoded and re-encoded in turn on your own machine, keeps its name with the extension swapped, and the set comes back as one ZIP. No upload, no queue, no per-day allowance.

This is the easy direction for a batch, because the outputs are the small half. Converting to BMP fills memory with uncompressed results; converting from it does the opposite, so the practical constraint is the 100 MB ceiling on any single input rather than the size of the set. A folder of 200 screen captures is unremarkable here.

When something downstream insists on it. Embedded displays, laboratory and industrial applications, point-of-sale hardware and older Windows programs read raw pixels rather than implementing a decoder, and a requirement is not something a converter can argue with.

Everywhere else there is no case for keeping it. PNG is lossless, opens in everything, and is a quarter of the size or better. Because the conversion loses nothing, the reverse trip is exact too — so keeping a BMP as insurance buys you only the disk space it costs.