Convert BMP to WebP

A 1920 by 1080 bitmap is 6.2 MB, and it is 6.2 MB whether it is a photograph or a flat banner, because the format writes three bytes per pixel and compresses none of them. Put that on a page and it is the page: everything else — the HTML, the CSS, the fonts, the scripts — is a rounding error next to it.

WebP was designed for exactly this position in a page. It spends bits where there is detail and nothing where there is not, which is why the same picture arrives in tens or hundreds of kilobytes instead. The conversion is not an optimisation on the margin; it is the difference between a page that loads on a phone and one that does not. It is also the difference between a largest-contentful-paint measurement that passes and one that cannot, since on a page with an image at the top of it the image is what the measurement is timing.

WebP can be lossless — the format carries both modes, and that is one of the reasons it exists. The encoder on this page writes the lossy variant, at quality 82 by default, because that is what a published image should be.

It is worth being clear about, because it means this conversion is not reversible. If what you actually wanted was an exact copy of the bitmap in a smaller container, this is the wrong page and PNG is the right one. If the image is going on a website, lossy is the correct answer and the quality number is the only thing to think about — and 82 is high enough that most people cannot tell the result from the source at normal size. The place to spend attention is not the dial but the dimensions, which is two sections below and matters considerably more.

WebP carries an alpha channel, and it carries one in lossy mode as well as lossless — which is unusual, and is the single strongest reason to choose it over JPEG for this source. Nothing in this conversion flattens the image or asks you for a background colour, because nothing needs to.

Most BMP files are 24-bit and have no alpha to preserve, so for them the point is moot. But the 32-bit variants do carry one, and a logo or an interface element exported by an older Windows tool is exactly the kind of file that has it. Sent to JPEG, that transparency becomes white — and on this site, without even the choice of which white. Sent to WebP, it stays transparency, at 256 levels rather than the single on-or-off value GIF would give it, so an anti-aliased edge still fades out properly against whatever the page puts behind it.

This is a hard limit in the format rather than a limit of this converter, and it is the one thing that can make the conversion impossible rather than merely lossy. Neither dimension of a WebP may exceed 16,383 pixels.

Ordinary images are nowhere near it — a 4000 by 3000 photograph has a great deal of room. What reaches it are the things that arrive as BMP: a large document scanned at high resolution, a stitched panorama, an output from a scientific instrument that produces a very wide strip. If your bitmap is one of those, reduce the width first or use PNG, whose own ceiling is over two billion pixels a side and therefore theoretical. It is worth checking the dimensions before converting a batch, because a single file that cannot become a WebP is a much more confusing outcome than one that comes out larger than expected.

WebP came out of Google in 2010 and spent its first decade with an asterisk next to it. That has ended: it is in every current browser, it is specified in RFC 9649, and design and content tools read it as a matter of course.

Which changes what the decision on this page is about. It is no longer whether the audience can see the image — it is only whether lossy is acceptable for this particular picture. That is a much easier question, and for anything being published the answer is usually yes. The registry gives WebP the same browser support value it gives JPEG and PNG: all. AVIF, the newer alternative, is still marked modern, and that one word is the practical difference between the two when you are choosing what to ship without a fallback.

The most common mistake in this direction is converting a bitmap at its original dimensions and putting it in a 600-pixel column. The browser then downloads several times the data it can display and scales the rest away, and no codec setting recovers that.

Set the maximum width to the widest the image will ever be rendered, doubled if it must stay sharp on a high-density screen. The resize happens in the same canvas pass as everything else here, so the picture is scaled once rather than twice, and the saving is proportional to the pixel count rather than to the width — halving the width removes three quarters of the data.

A large share of BMP files are screen captures, and lossy encoders treat text badly — the hard edges of type are exactly the high-frequency content they are built to discard. That is a strong argument against JPEG for this material and a weaker one against WebP, which handles sharp boundaries better at the same setting but does not make them free.

For a screenshot that has to be readable, the honest ranking is PNG first, then WebP at a raised quality, then JPEG a long way behind. PNG will often be the smaller file as well, since flat regions and hard edges are what lossless compression is best at and what lossy compression is worst at — so on this material the usual trade does not even apply. For a photograph, WebP at 82 with no adjustment is the right answer and the ranking does not matter.

The registry records no metadata containers for BMP: no EXIF, no XMP, no embedded ICC profile. WebP can carry all three, and there is nothing in the source to fill them with.

For a web image that is mostly convenient — the file is as small as the pixels allow and carries nothing that identifies where it came from. It matters if the bitmap came out of a colour-managed pipeline and was expected to be interpreted in a particular space, because the WebP will be read as sRGB and nothing on this path says otherwise.

Drop the folder. Each bitmap is decoded and re-encoded in turn on your own machine, keeps its filename with the extension swapped, and the whole set comes back as one ZIP. There is no queue, no account and no daily allowance, and the per-file ceiling is 100 MB.

Doing it locally matters more here than the speed does. Images for a site that has not launched, product photographs under embargo, screenshots of an internal tool — all of that would otherwise be handed to a third party in exchange for a compression pass you can run yourself.

Each converted file keeps its original name with the extension changed, which is what makes a batch usable but is also where the work is not finished. Every reference to the old file — in a template, in a stylesheet, in a content entry, in a manifest — still points at a name ending in .bmp, and a missing image is a more visible failure than a large one.

The other half is remembering to remove the bitmaps from whatever gets deployed. A build that copies an assets directory wholesale will ship both copies, which means the repository grows, the deployment grows, and the megabytes this conversion was meant to remove are still being transferred somewhere. Convert, update the references, delete the originals from the project, and keep the bitmaps outside it if they are the only masters you have.