Convert WebP to BMP

How it works

The server decodes the WebP into an image buffer, then passes the pixels to a BMP encoder. WebP and BMP do not share a compressed bitstream, so changing the suffix would not work: the source must be read and the image must be written again. The dimensions are preserved, while the target's channel layout and bitmap storage rules determine the resulting file size.

For a photographic WebP, this is a deliberately asymmetric conversion. WebP may have used prediction, transforms, and quantization to describe a convincing image with very few bytes. BMP generally stores rows of color samples with little or no compression. The output therefore represents the decoded image faithfully at its new pixel values, but it is not a better original and it may be unsuitable for email attachments, cloud quotas, or web publishing.

When BMP is the right bridge

Use this page when a known destination insists on BMP: an old graphics package, a machine-control panel, a printer workflow, or a script built around bitmap input. The value is predictable compatibility with software whose format list predates WebP. Confirm whether that destination wants a particular bit depth, color mode, or maximum dimensions before converting a whole folder.

Do not use BMP as a default web format or as a way to make a lossy image lossless. For a browser asset, WebP is normally smaller and more appropriate. For editing, PNG may offer a less wasteful lossless intermediate, and for preservation the original camera or design source is preferable. Treat the BMP as a disposable working copy made for a specific older tool, and retain the WebP beside it until the job is complete.

You can calculate the output size before you convert

BMP stores pixels, so its size is arithmetic rather than a surprise: width × height × bytes per pixel, plus a header of a few dozen bytes.

At 24 bits — three bytes for red, green and blue — a 1920 × 1080 image is 1920 × 1080 × 3, about 6.2 MB, whatever the picture contains. A photograph and a plain white rectangle of the same dimensions produce the same file, because nothing is looking for redundancy. The same source as WebP might be 200 KB, so a thirtyfold increase is the ordinary case rather than the bad one.

Two details adjust it. Rows are padded to a multiple of four bytes, which matters only at awkward widths. And if the WebP carries transparency the encoder writes 32-bit output, four bytes per pixel, adding another third.

The practical use of this is deciding before you start. A folder of a hundred phone photographs at twelve megapixels converts to roughly 3.6 GB of BMP. That is not a reason to avoid the format when a machine requires it, but it is a reason to check the destination's disk, its maximum file size, and whether it wants the images resized first.

Transparency and animation do not survive the same way

WebP does two things BMP was never designed for, and the conversion handles them very differently.

Transparency mostly survives. A WebP with an alpha channel produces a 32-bit BMP that keeps it — but support for that is genuinely uneven, because the alpha channel was a late addition to a format from 1990. Older graphics packages, and some machine-control software, read the file as 24-bit and either ignore the alpha or display the transparent regions as black. If the destination is the kind of legacy tool that motivated using BMP at all, assume it will not understand alpha, and composite the image onto a known background color before converting rather than discovering it afterwards.

Animation does not survive at all. An animated WebP is a sequence of frames; BMP holds exactly one image and has no concept of a second. The conversion takes the first frame and discards the rest, which is the only sensible behavior and is silent — you get a valid BMP that happens to be the opening moment of the animation. If you need the frames, extract them before converting, and expect one large BMP per frame.