Convert BMP to SVG

Every other conversion on this site takes a picture and writes the same picture in another format. This one cannot, because there are no shapes in a bitmap to carry across — a BMP is a grid of colour values and nothing else, with no record of the logo, the letters or the lines that produced it.

So the tracer guesses. It finds boundaries between areas of similar colour and draws a path around each one, and the result is a new drawing that happens to resemble the old picture. That guess is what tracing is, and it is why this page spends its length on which images it guesses well about rather than on settings. It is also why nothing here tries to predict the outcome from the file: a colour-count heuristic would be a guess about a guess, and the real answer is available for free a moment later by looking at what came out.

Flat regions with real boundaries between them: a logo, a wordmark, an icon, a flat illustration, a schematic, a scanned line drawing. That material is made of exactly the thing the algorithm looks for, so the output is a small set of clean paths that scale to any size without going soft.

Measured before this was built rather than after: a flat logo round-tripped faithfully — sharp edges, correct colours, rounded corners intact — and 6 KB of PNG became 16 KB of SVG that now scales to a billboard. Larger, and worth it, because the larger file is the one that can be printed at a metre wide. That is the shape of a successful trace on this page: a modest increase in bytes in exchange for resolution independence. If the output is many times the input rather than a few times it, the trace did not work and the next two sections explain why.

What comes out is a list of filled paths, so Inkscape, Illustrator and Figma will all open it and let you select a shape, recolour it, move it or delete it. For a recovered logo that is usually the whole job: trace at four or eight colours, delete the stray specks the tracer left along the edges, set the fills to the exact brand values, and the artwork is usable again.

How pleasant that is depends entirely on the shape count. A clean mark traced at four colours is a handful of paths and behaves like something a person drew. A traced photograph is thousands of overlapping blobs with no structure, no names and no grouping, and editing it is not meaningfully easier than redrawing the picture. The paths also do not correspond to anything: there is no path that is "the letter A", only the outline of a region that happened to be one colour.

It posterises it. A photograph has no flat regions — a sky is a continuous gradient and a face is a continuous gradient — so the tracer manufactures the boundaries it needs by reducing the picture to a handful of colours first, and then outlines those.

The measured outcome is the one to expect: a photograph came out four times larger than the compressed original and visibly posterised. Both halves of that are bad, which is unusual — most trade-offs here give you something in exchange. If the goal was to make a photograph scale, nothing achieves it, and the right move is to keep the pixels and use the largest version you have.

A screenshot containing text produced an SVG forty times the size of the PNG. Every anti-aliased letter is a cluster of slightly different greys, and each of those becomes its own small path, so a paragraph of text turns into thousands of shapes that together look like slightly wrong text.

Since screen captures are one of the commonest things to arrive as a BMP, this is worth saying loudly. If the point was the words, the BMP to TXT conversion reads them. If the point was a sharp image of the interface, PNG keeps every pixel exactly and is a fraction of the size of either the bitmap or the trace.

Four colours for a single-colour mark or a simple logo, eight for a flat illustration, sixteen where there is real shading, thirty-two only when the result is visibly missing something. The default is eight and it is the right starting point for most artwork that arrives as a bitmap.

The cost of raising it is not linear in any way that feels fair. Each additional colour is another complete set of regions to outline, so the shape count and the file size climb quickly while the visual improvement flattens. Trying eight and then sixteen takes twenty seconds and settles the question better than reasoning about it does. There is a second reason to keep the number low that has nothing to do with size: a logo traced at four colours is something you can tidy up afterwards, and one traced at thirty-two is something you can only accept or discard.

The detail setting controls how closely the paths follow the pixels. Smooth accepts a looser fit and discards any shape below sixteen pixels, which removes the specks that anti-aliasing leaves along every edge. Sharp keeps shapes down to two pixels and follows the grid closely. Balanced sits between them and is the default.

Smooth is usually right for a logo and sharp is usually right for a technical drawing where a thin line matters. What the setting never does is blur the image first: that would reduce the speck count by softening exactly the hard edges that were the only reason to trace a logo, so the blur radius stays at zero on every setting.

Tracing cost grows with the number of edges rather than with the file size, and a large photograph has an edge almost everywhere. Left alone, a twelve-megapixel source can produce a multi-megabyte SVG over tens of seconds — a worse outcome than the one the visitor was trying to avoid.

Scaling down first is not the loss it would be in a raster conversion. The output is resolution-independent, so a logo traced at 1,600 pixels wide and the same logo traced at 4,000 render identically at any size; what changes is only how tightly the paths hug the original pixel grid. Since a BMP is uncompressed and therefore often enormous, this ceiling is reached on this page more than on any other.

After tracing, the two byte counts are measured and compared, and the interface says which way it went. That warning is the honest core of the feature — no heuristic predicts whether a trace will work, but the answer is available for free a moment later.

It needs a correction when the source is a bitmap. Against three uncompressed bytes per pixel almost anything looks like a win, so a traced photograph can be smaller than its 36 MB BMP while being four times larger than a PNG of the same picture and considerably worse. Convert the bitmap to PNG as well and compare against that number instead; it is the one that reflects what tracing actually cost. The measurements quoted above are all against compressed originals for the same reason — a comparison against an uncompressed bitmap would have made every one of them look like a success, including the photograph.

The tracing is done by imagetracerjs: 46 KB, pure JavaScript, released under the Unlicense. It is not the best tracer available. potrace and autotrace produce cleaner curves and are GPL; VTracer produces the best output of the four and is properly licensed, but its only browser packaging declares no licence at all, which this project treats as blocked rather than as permissive.

What that buys is a conversion that runs entirely in your browser. The bitmap is decoded, scaled and traced in the tab, nothing is uploaded, and there is no account or daily allowance — which matters, because the artwork people try to recover this way is almost always a logo somebody owns.