Convert WebP to BMP

This is the first thing to expect and it catches people out, because every other conversion they have done made the file smaller. WebP exists to compress an image for delivery; BMP exists to store a rectangle of pixels with no decoding work at all. The arithmetic is exactly three bytes per pixel plus a 54-byte header, whatever the picture is.

This site’s own samples make it concrete at 480 by 320 pixels: the photograph is 14,700 bytes as WebP and 460,854 as BMP, the screenshot-like scene 10,830 against the same 460,854, and the flat graphic 4,428 against 460,854. The BMP figure never changes because the content is irrelevant to an uncompressed format. Scale that to a 4,000-pixel image saved off a photography site and the BMP is around 48 MB — worth knowing before you convert a folder of them.

WebP is two formats wearing one extension: a still image and an animation. Plenty of the small looping graphics on the web are the second kind, and the decoder used here handles only the first. The result is a refusal with a readable message rather than a silent conversion of frame one.

That is the better of the two available failures and it is deliberate: a converter that quietly hands back a tenth of a file is the thing this site exists not to be. Both a lossy and a lossless animated WebP were tested against the decoder and both were rejected. If you only wanted one frame, open the file in a browser, pause it and screenshot the frame you want. If the animation itself has to survive, WebP to GIF is the conversion that keeps it, and BMP could never have held it.

24-bit and uncompressed, with a BITMAPINFOHEADER — the baseline that every BMP reader ever written understands, including the ones inside embedded devices where the parser is two hundred lines of C. There is no palette, no run-length encoding and no V5 header.

Three details matter if you are writing the code that consumes the file. The rows are stored bottom to top, so an image that arrives upside down means the reader assumed otherwise. The channels are ordered blue, green, red rather than the other way round, so a picture with the reds and blues swapped means the same. And every row is padded out to a multiple of four bytes, which is what produces a diagonal skew if the stride is computed as width times three. All three are in the specification. The resolution field is written as 2,835 pixels per metre, which is 72 dpi; a zero there makes some older viewers refuse the file outright, which is why a real number goes in.

WebP carries a real alpha channel and a great many images saved from web pages use it — logos, badges, product cut-outs, anything designed to sit on a page background. The BMP written here has no alpha, so the picture is composited onto a solid colour before encoding, in the same pass as any resizing so that no fringe of half-transparent pixels is left behind.

The colour is white by default and there is a control for it. Set it on purpose when the destination is a machine rather than a person: an inspection routine that thresholds the image, or a display driver that treats one colour as its transparency key, behaves completely differently against white than against black or magenta. If the transparency is the point — a mask, an overlay, a logo that must sit on an unknown background — then BMP cannot express it and WebP to PNG is the conversion that can.

A WebP can be lossy or lossless and the extension does not tell you which. If it was lossy — which most images served from websites are — the encoder has already smoothed flat areas and rung along hard edges, and those are now the pixels. Writing them into an uncompressed container preserves them exactly and recovers nothing.

This matters because "uncompressed" reads like "high quality" and is not the same thing. The BMP is a faithful copy of a picture that has already been compromised, thirty times larger and no better. If the original is available in another form — the PNG fallback many sites serve alongside the WebP, or the file before it was uploaded — converting that instead is the only thing that actually improves the result.

It is worth five minutes with the documentation before accepting a thirty-fold increase in size. A great many embedded, laboratory and industrial tools that list BMP also accept PNG, which is lossless, dramatically smaller, carries transparency and has a decoder available for every platform. Where both are listed, PNG is the better choice on every axis.

The genuine BMP-only cases are real and narrow: a parser someone wrote in-house, a display controller with kilobytes of ROM, a program compiled in 1997 that nobody can rebuild, or a course assignment that specifies the format because reading it is the exercise. Those are the situations this page is for, and in all of them the size is somebody else’s constraint rather than a decision you are making.

Since the output size is purely a function of pixel count, reducing the dimensions is the only lever that exists. The maximum-width option scales the image before encoding, using a filtered downscale rather than dropping pixels, so text and edges stay clean rather than aliasing into a staircase.

Whether to use it depends entirely on the destination. An embedded display with a 480 by 272 panel gains nothing from a 2,000-pixel source and will spend real time and memory on it; a machine-vision routine expecting a specific resolution needs exactly that resolution and nothing else. BMP itself imposes no ceiling — unlike WebP, which cannot exceed 16,383 pixels on an edge — so the limit here is what the reader on the other end can hold in memory.

If the problem is simply that ordinary software will not open the file, WebP to PNG is the answer nearly every time: lossless, universally supported, transparency intact, and a small fraction of the BMP’s size. If the destination is a person — an email, a print shop, a photo service — WebP to JPG is what they are expecting.

If the picture needs to go into a document or a submission that names a format, WebP to PDF and WebP to TIFF both exist and are more likely to be what a form is asking for than BMP is. BMP earns its place only when something inflexible has named it, which is the assumption this page is written on.

libwebp compiled to WebAssembly decodes the file and the BMP is written by hand in a few dozen lines, because the format is a header followed by pixels and does not justify shipping an image library. Nothing is uploaded, there is no account, and the codec is fetched only when a WebP is actually dropped.

The free limit is 100 MB per file, which is far more than any WebP will ever be — the constraint on this page is the output rather than the input. Batches work: drop a folder, each file converts with its own progress row, and the results come back as a ZIP. Because every BMP is three bytes per pixel, that ZIP can be very large indeed, so a batch of high-resolution downloads is worth converting in groups rather than all at once.