Convert SVG to BMP

These two formats sit at opposite ends of everything. An SVG is text: a list of paths, fills and transforms that a renderer turns into a picture at whatever size is asked for, so the file has no resolution and no fixed byte cost. A BMP is the picture already made, stored as literal rows of colour with no compression, no structure and nothing to interpret.

That gap is the whole subject of this page. Going one way is a rendering — a decision about size, background and antialiasing, taken once and then permanent. Going the other way is not possible; there is no path from a grid of bytes back to the shapes that drew it.

A width and height attribute on an SVG is a suggestion, not a size — the drawing is defined by its viewBox and can be produced at any resolution. So the conversion has to pick one, and the scale setting is that decision. The default renders 1,024 pixels wide and the height follows the drawing’s proportions; the scale runs from 0.1 to 10, giving anything from 102 to 10,240 pixels.

Pick the number the destination actually needs rather than the largest available, because the cost here is unusually steep. Unlike PNG or WebP, a bitmap’s size does not depend on what is in the picture at all: doubling the width quadruples the file whether the drawing is a full illustration or a single black line.

Every pixel takes three bytes — blue, green and red, in that order — and each row is padded up to a multiple of four. Add a 54-byte header and that is the entire file. A 1,024-pixel square is 3,072 bytes a row and 3,145,728 bytes of image data, giving 3,145,782 in total.

So an SVG of a few hundred bytes becomes roughly three megabytes at the default setting, and about twelve at scale 2. This is not a defect of the converter; it is what BMP is, and it is the reason anything that has a choice picks another format. If the destination has a size limit, do the multiplication before converting rather than after.

The bitmap written here is 24 bits per pixel with no fourth channel. There is a header variant that defines alpha, and files using it exist, but support for it is exactly the sort of thing BMP is usually chosen to avoid — so the transparency has to be resolved first.

The drawing is rendered onto nothing and then flattened onto the background colour in a single pass, which matters: filling first and scaling afterwards would bleed the fill into the edges, and scaling a transparent image before flattening leaves a fringe of half-transparent pixels that the fill then darkens. Set the colour to whatever surface the bitmap will sit on. White is the default and is wrong on a dark panel.

The rendering is done by resvg compiled to WebAssembly rather than by the browser’s own SVG engine, and that is deliberate. Handing an SVG to a canvas gives whatever that browser feels like: different text metrics, different filter support, visibly different results for the same file in Chrome and Safari. One renderer means the bitmap is identical on every machine that produces it.

That matters more here than on most targets. A bitmap going onto a device or into an installer is usually checked once and then trusted forever, sometimes compared byte for byte against a reference. A rendering that varies by browser would make that comparison meaningless.

SVG stores text as text and refers to a typeface by name. If the font is not embedded in the file, the renderer picks something else, and a carefully spaced wordmark comes back with different letterforms and different spacing. This is the single most common reason a rendered SVG looks wrong.

The fix belongs in the design tool, not here: convert text to outlines or paths before exporting, and the letters become shapes that nothing can swap. It also makes the file safe to hand to anyone else, which is worth doing anyway if the drawing is going into a system you do not control.

Because reading one needs no library. A microcontroller driving a small display can seek past the 54-byte header and copy bytes into a framebuffer with a loop; supporting PNG on the same device means adding a decompressor, a memory allocator and a chunk parser to something that may have 32 KB of RAM.

The same logic covers installer resources loaded through the platform’s own bitmap calls, older Windows controls, and test fixtures that compare images without a codec in the way. In each case the format is chosen for predictability, and the megabytes are the price of it.

Delete the bitmap and you can make another. Delete the SVG and the bitmap is all there is, and everything that made the drawing useful — editability, arbitrary resolution, a text-diffable history in version control — is gone for good. Tracing a BMP back into paths guesses at the edges and produces a different file with more nodes and worse curves.

Treat the conversion as an export step, ideally one your build runs rather than one somebody does by hand. When the panel needs a different size next year, re-render from the vector instead of scaling a three-megabyte bitmap.

Drop the whole set. Every file is rendered at the same scale and flattened onto the same background, which is usually what these destinations need — a set of panel graphics that disagree about their backgrounds looks worse than any of them being individually imperfect.

Watch the total size. Twenty drawings at the default scale is around sixty megabytes of bitmap before the ZIP, which is enough to be slow on a phone and enough to fill a small device’s storage. Reducing the scale to what the display actually shows is the single most effective thing you can do to that number.