Convert JXL to BMP

Microsoft published BMP in 1987 and it has been legacy for most of the time since, yet the demand does not go away. Firmware build scripts, LED panels and small displays, laboratory and machine-vision software, older Windows applications, emulator and game modding toolchains — a great deal of code was written to read a bitmap header and index straight into pixels, and none of it will ever learn a new format.

JPEG XL is the opposite of that. It was standardised as ISO/IEC 18181-1 in 2022, it is in almost no consumer software, and decoding it requires a modern codec that the machine on the other end of your workflow certainly does not have. Converting is not a preference here; it is the only way the pixels arrive in a shape the receiver can address. The gap between the two formats is thirty-five years, and the older one is the one that has to be accommodated.

The BMP written here has no compression of any kind. The file is a 14-byte file header, a 40-byte information header, and then the pixels — three bytes each, blue first. A 4,000 by 3,000 image comes to exactly 36,000,054 bytes, about 34 MiB, and it is the same 34 MiB whether the photograph is a detailed forest or a plain white field.

Against a JPEG XL of perhaps three megabytes that is a factor of eleven, and against the 46 MiB the same image would occupy as an uncompressed TIFF it is the one saving BMP offers, since BMP drops the alpha channel that TIFF keeps. Nothing on this page will make the file smaller except reducing the pixel count. Compress it afterwards if it has to be sent — a ZIP finds a great deal of redundancy in a raw bitmap, and on flat graphics it will recover most of the difference.

BMP predates every convention a modern format follows. The rows are stored from the bottom of the image upwards, the channels run blue, green, red rather than red, green, blue, and the header records the resolution as 2,835 pixels per metre, which is 72 dpi. All three are in the specification rather than the result of a shortcut here.

The variant produced is 24 bits per pixel with a BITMAPINFOHEADER, which is the oldest and most widely accepted combination — no colour table, no bitfield masks, no compression tag to interpret. If the software you are feeding was written against the Windows API at any point in the last thirty years, this is the shape it expects, and the odd conventions are precisely why it will work. The 72 dpi figure in the header is written because a zero there makes some older viewers reject the file outright; nothing reads it for any other purpose.

JPEG XL carries a full alpha channel and the 24-bit BMP has nowhere to put it. Before the file is written the image is composited onto a background colour, which you choose on this page, and once that is done the original edge information is gone.

Choose the colour the image will actually be displayed against rather than a default. White is right for a document or a print preview; black is right for a display panel or an overlay that runs on a dark surface; magenta is right if the receiving software treats a specific colour as a transparency key, which a surprising amount of older game and display tooling does. Getting this wrong shows up as a coloured fringe around every soft edge, and the only fix is to convert again from the JPEG XL.

Every row in a BMP is padded to a multiple of four bytes. At 24 bits per pixel a width divisible by four needs no padding at all, while a width of 1,001 pixels produces rows of 3,003 bytes and one padding byte each. The converter writes those bytes; they are part of the format, not slack.

This is the detail that breaks hand-written readers, and it is worth knowing if you are the one writing the code at the far end. Software that assumes the stride equals width times three will read a correct BMP as a progressively skewed image — the classic diagonal smear. If your output looks sheared, the padding is where to look, and choosing a width divisible by four sidesteps it entirely.

JPEG XL can hold EXIF, XMP and an ICC profile. BMP has no standard place for any of them, and this conversion decodes to raw pixels and writes them out, so the camera model, the capture date, the GPS coordinates and the colour profile all stop here. That is unconditional: the page has no switch that keeps any of it, because the encoder never sees it in the first place.

That is a privacy improvement and a colour hazard in the same step. There is no profile in the output, so whatever reads the BMP will interpret the numbers as ordinary sRGB — which is fine for a display panel or an instrument and wrong for a wide-gamut photograph you cared about. Where the colour is the point, keep the JPEG XL as the reference copy.

Every lossy target on this site offers a quality number. This one does not, and its absence is honest rather than an omission: BMP records the pixel values it was given, so there is no rate to set and no detail to spend. Two conversions of the same JPEG XL produce byte-identical files.

What that leaves is the pixel count, and the maximum-width control is therefore the only setting with any effect on the result. Halving the width quarters the file, from 34 MiB to about 8.6 MiB on the example above. If the destination is a 320 by 240 display, resize to 320 pixels and the whole conversation about size disappears.

PNG does everything BMP does and more: lossless, an alpha channel that survives, and a file typically a fraction of the size. It has been readable by everything since 1996 and there is no image-quality argument for BMP over it. If the software at the other end will take a PNG, that is the conversion to run instead of this one.

BMP wins in exactly one situation, and it is a real one: the receiving code wants to read a header and then treat the rest of the file as an addressable array of pixels, with no decoder in the loop. Firmware, embedded displays and instrument software are full of that pattern. When that is the constraint, the size is not a drawback, it is the specification. TIFF is the other candidate in that situation, and it is worth checking which of the two your tool prefers before assuming BMP.

BMP is a family rather than a single layout. It also defines 1-, 4- and 8-bit paletted images with a colour table, 16-bit packed forms, and a 32-bit variant that can carry an alpha channel through bitfield masks. This converter writes one member of that family — 24-bit, uncompressed, no colour table — because it is the one nothing refuses.

If the thing you are feeding demands a specific variant, say an 8-bit indexed bitmap for a small display or a 32-bit BMP that keeps transparency, this conversion will not satisfy it and no setting here will change that. Those are jobs for a tool that lets you name the pixel format outright, such as ImageMagick, and it is better to know that before you convert a folder than after the loader rejects the first file.

The decode, the flatten and the bitmap write all happen in your browser, so nothing is uploaded and there is no queue. Files up to 100 MB are accepted on the free tier, and that ceiling applies to the JPEG XL going in rather than to the bitmap coming out — a 100-megapixel source would produce a 300 MB BMP, which is a question of your machine's memory rather than of any limit here.

Drop a folder to convert a set in one pass; each file keeps its name with the extension swapped and the batch returns as a ZIP, which for uncompressed bitmaps is a considerably smaller download than the files themselves. Keep the JPEG XL originals: the BMP holds the pixels but not the transparency, the metadata or the depth that were in them.