Convert GIF to BMP

These two formats are almost the same age — 1987 and 1990 — and they solve the same problem in opposite directions. A GIF stores an index into a palette of at most 256 entries, which is one byte per pixel before LZW compression squeezes it further. The bitmap written here stores a full blue, green and red triple for every pixel, uncompressed.

So the growth is not one factor but two multiplied together. Three bytes where the GIF used one, and none of the LZW saving that made the GIF small in the first place. A 40 KB GIF routinely becomes a bitmap ten times its size, and on flat artwork with long runs of identical colour — the material GIF compresses best — the ratio is worse still.

The arithmetic is short and there is no estimation in it. Multiply the width by three to get the bytes in one row, round that up to the next multiple of four, multiply by the height, and add 54 bytes of header. A 480 by 270 GIF gives 1,440 bytes per row, no rounding needed, 388,800 bytes of pixels and 388,854 in total.

Nothing about the source changes that number. The same 480 by 270 bitmap comes out of a heavily dithered photograph and out of a solid red rectangle, because the format stores every pixel literally in both cases. That predictability is the reason hardware asks for bitmaps: firmware that reads one can allocate its buffer from the header alone.

Two conventions in the bitmap this writes look like mistakes and are not. The rows are stored from the bottom of the image upwards, and the channels within each pixel are ordered blue, green, red rather than the other way around. Both are in the original specification and both are what a reader of BMP files expects to find.

The third is the padding. Every row is padded out to a multiple of four bytes, so a 101-pixel-wide image writes 303 bytes of pixels followed by one byte of nothing, 304 bytes per row. Code that reads a bitmap by assuming width times three per row produces a picture that shears diagonally, which is the single most common bug in a hand-written BMP reader.

BMP holds one picture. It has no concept of a sequence, a delay or a loop, so an animated GIF arriving here becomes the frame it opens on and the rest is discarded — the registry states this as the caveat on the pair rather than leaving it to be discovered.

For the destinations that ask for bitmaps this is rarely a problem, because a device that wants a BMP wants a static image by definition. It is worth checking that the first frame is the one you want: plenty of GIFs open on a blank or a title card before the content begins.

It is a reasonable expectation that an image with only 256 distinct colours would produce a small file, and for a paletted format it would. The bitmap specification even permits exactly that — an 8-bit BMP with a colour table, which would map onto a GIF almost perfectly.

This converter does not write one. Every bitmap it produces is 24-bit, so a GIF using six colours costs the same bytes as a photograph of the same dimensions. If the device you are feeding specifically requires an 8-bit paletted bitmap rather than merely accepting a BMP, this file will not do, and that is worth establishing before the conversion rather than after the device rejects it.

A GIF can nominate one palette entry as transparent. The bitmap written here has no alpha channel at all — 24 bits, three channels, nothing left over — so those pixels have to be given a value before encoding.

The background colour option decides what that value is, and it defaults to white. Choosing it deliberately matters on hardware: an icon destined for a display with a black interface should be flattened onto black, not onto white and then inverted later. Where a system expects a chroma key, set the option to that exact colour rather than trusting a later step to find it.

There is no quality slider on this conversion and there could not be: uncompressed means uncompressed, and there is nothing to trade. The only lever is the maximum width, which resizes the picture before the pixels are written and therefore changes the file size quadratically.

Halving the width quarters the bitmap. That is usually the right move when the target is a small display anyway — a 128-pixel-wide panel gains nothing from a 640-pixel source, and scaling here rather than in the firmware means the device does not have to hold the larger buffer at all.

Every raster conversion here strips metadata on the way through, unconditionally, and on this pair that rule has very little to do. A GIF has no EXIF block, no camera model, no GPS coordinates; the most it usually carries is a comment extension and an application extension left by whatever wrote it.

The bitmap format has nowhere to put any of that in any case. Its header describes dimensions, bit depth and little else, so what comes out is pixels and geometry. If the GIF came from a screen recorder that stamped its name into a comment block, that name does not travel.

The GIF is decoded by the browser’s own image support and the bitmap header and pixel rows are written in JavaScript in the same tab. There is no server in the path, no upload and no account, and the file is gone when the tab closes.

This matters more than it sounds for this pair, because the things people convert to BMP are frequently internal: a control panel graphic, a product label, an instrument’s splash screen. None of that needs to pass through anyone else’s infrastructure to become a bitmap.