Convert HEIF to BMP

BMP is a legacy format and this page is not going to pretend otherwise. It has no compression worth the name, no metadata, and no advantage over PNG on any axis a person would care about. Microsoft published it in 1987, the 40-byte header this page writes arrived with Windows 3.0 in 1990, and the world moved on.

What keeps it alive is software that never did. Instrument control panels, kiosk displays, embedded splash screens, firmware image loaders, internal tools compiled once in 2003 and never touched: these read a bitmap because a bitmap is trivial to parse with no library at all. If that is your situation, BMP is not a bad choice, it is the only one, and everything below is about getting the bytes right.

A 14-byte file header beginning with the two characters BM, then a 40-byte BITMAPINFOHEADER declaring one colour plane and 24 bits per pixel, then the pixel data. Three bytes per pixel in blue-green-red order, which is the order the specification asks for and not a mistake. Rows are stored bottom to top, which is also the specification.

Each row is padded to a multiple of four bytes. For a width of 4,032 that is 12,096 bytes with no padding needed; for a width of 4,031 it is 12,093 bytes plus three bytes of padding. A parser that assumes rows are contiguous will read every row after the first one skewed, which is the classic failure when somebody writes their own BMP loader.

Because nothing is compressed, you can calculate the output before converting: the padded row length times the height, plus 54 bytes of header. A twelve-megapixel photograph at 4,032 by 3,024 comes to 36,578,304 bytes of pixel data — about 36.6 MB — from a HEIF that was probably two or three.

A factor of fifteen or so is the normal outcome, and it is the reason the maximum-width field matters more here than on almost any other pair. If the software you are feeding displays the picture at 1,024 pixels wide, converting at 1,024 wide gives it what it needs in about 3 MB instead of 36.

The writer produces 24-bit pixels, so there is no room for transparency. Anything transparent in the source is flattened first and only then encoded, and what it is flattened onto is the background colour above the drop zone. It starts at white; the control was extended to HEIC and HEIF sources in August 2026, having previously been offered only from PNG, WebP and the other formats the site expected to carry alpha.

For a photograph, which is what a .heif file almost always holds, there is nothing to flatten and the point is academic. It matters if the source is an exported graphic with a cut-out, and in that case PNG keeps the transparency and BMP cannot.

Every pixel the HEIF decoder produced is written into the BMP literally, so this direction adds no compression artefacts of its own. In that narrow sense it is a lossless conversion and the file is a faithful record of the decode.

It does not undo anything. The camera compressed the photograph when it wrote the HEIF, and those decisions are baked into the pixels the decoder hands over. A 36 MB bitmap of a 2 MB photograph contains exactly as much picture as the 2 MB did, stored far less cleverly.

HEIF is specified to ten bits per channel and can carry wide colour. A 24-bit BMP holds eight bits per channel and has no concept of a colour space at all — there is nowhere in the header to say what the numbers mean.

So the conversion truncates, and the receiving software will interpret the values as ordinary sRGB because that is the only reasonable default. For the kind of program that requires a BMP this is invariably fine; it is worth knowing only if the picture is a calibrated measurement rather than a photograph.

The BMP contains no EXIF, no timestamp, no camera model and no GPS coordinates. Two separate reasons converge on that: the conversion decodes to raw pixels and re-encodes, which no metadata block survives, and the format has essentially nowhere to store any of it even if it did.

That is occasionally the whole point. Feeding a picture to a system that will store it, index it or display it publicly, a bitmap is about as inert a container as exists — pixels, dimensions, and nothing that identifies the photographer or the place.

Everything, which is the format's one genuine strength. Microsoft Paint, GIMP and IrfanView all open it, every Windows API since the beginning has understood it, and browsers display it — BMP is one of the few formats here whose browser support is recorded as complete, which makes checking the output as easy as opening it in a tab.

That check is worth doing once per batch. If a picture appears upside down or with its colours swapped in whatever custom software you are feeding, the cause is nearly always a reader that assumes top-to-bottom rows or RGB order, and the file is right.

The decoder and the bitmap writer both run in the browser tab, so no photograph is uploaded and nothing is queued. That is a practical point for the readers this page is written for, whose files are frequently pictures of a production line, a patient record, a site survey or something else that is not supposed to leave the building.

The free tier takes inputs up to 100 MB, which no HEIF will trouble; the outputs are the large half here. A folder converts with a progress row each, and an "all as ZIP" button appears once two are done — worth using, since uncompressed bitmaps compress well inside a ZIP.

There is no way back. This site reads HEIF with libheif under LGPL-3.0 and cannot write the format at all, because that would need an HEVC encoder under a licence a static site cannot satisfy.

Since a bitmap is fifteen times the size and holds strictly less information, the sensible practice is to treat it as output rather than as a copy: generate it for the machine that needs it, use it, delete it, and keep the HEIF, which can produce another one whenever the old software asks again.

A fair number of people converting to BMP are feeding a parser they wrote, because a bitmap is the one image format you can read in thirty lines with no library at all. Three details account for nearly every bug in those thirty lines, and all three are in the file this page produces.

The row stride is the padded length, not the width times three — compute it as the width times three rounded up to a multiple of four, and advance by that between rows. The rows run bottom to top, so the first row in the file is the last row of the picture. The channels are stored blue, green, red, in that order. Get any of the three wrong and the image is skewed, upside down or blue-tinted, and it will look like a corrupted file rather than a wrong assumption.

PNG is lossless too, so it discards nothing a bitmap would have kept, and it is a fraction of the size — the same twelve-megapixel picture that becomes 36.6 MB here typically lands under 20 MB as a PNG and often far below that. It also carries an alpha channel and a checksum on every chunk, so a truncated file is detected rather than silently displayed with garbage at the bottom.

The two things BMP has that PNG does not are the reasons to be on this page: the pixel layout is fixed and trivially parseable with no decompression at all, and any software of any age accepts it. If your receiving system is a modern application that merely happens to have BMP in its file dialogue, PNG is the better file. If it is a machine, a firmware image or a program compiled two decades ago, stay here.