Initializing... drag & drop files here
Supports: BMP
.bmp files are accepted on this page — for .jpg or .png start at JPG to SVG or PNG to SVG. Batch upload is supported; every file is traced in your browser session.<path> elements. Download files individually or as a ZIP. No sign-up, no watermark, no email gating.BMP is Microsoft's uncompressed (or optionally RLE-compressed) raster format, native to Windows since version 3.0 in 1990. Each pixel is stored explicitly, so a 1024×1024 24-bit BMP weighs 3 MB before any header overhead and pixelates the moment you scale it past its native size. SVG, standardised by the W3C since 1999 (SVG 1.1 Second Edition was given Recommendation status on 16 August 2011), describes shapes as XML paths — geometry, not pixels — so the same logo prints crisp on a business card or a billboard from one file.
Tracing a BMP to SVG only makes sense for art that should have been vector to begin with. Typical wins:
<img src>), and Figma — sharp on every DPR, from a 1× laptop screen to a 3× Android phone.For animation or interactive states, SVG also exposes every shape to CSS and JavaScript — something a flattened BMP can never offer.
| Property | BMP (raster) | SVG (vector) |
|---|---|---|
| Type | Pixel grid (Microsoft DIB) | XML markup of paths, shapes, text |
| Standard body | Microsoft (Windows 3.0, 1990) | W3C — SVG 1.1 Second Edition (Aug 2011); SVG 2 Candidate Recommendation since Oct 2018 |
| Compression | None, or RLE for 4/8-bit; large files | XML compressible to ~30% with gzip / SVGZ |
| Scaling | Pixelates above native size | Lossless at any size |
| Alpha / transparency | Only 32-bit BMP with BITMAPV4HEADER+ supports an alpha channel; 24-bit BMP has none | Full per-shape opacity, masks, gradients |
| Animation | Not in the format | CSS, SMIL, and JavaScript animation |
| Editable in code | No | Yes — XML in any text editor; styled with CSS |
| Browser support | Limited modern adoption; works in <img> in most browsers but not preferred |
Native in Chrome, Firefox, Edge, Safari, Opera; partial in IE 9-11 |
| Best for | Screenshots, intermediate Windows processing, embedded systems | Logos, icons, illustrations, UI, print artwork |
| Typical size — simple logo | 50-500 KB | 5-50 KB |
| Source image | Expected result | Notes |
|---|---|---|
| Two-colour logo, sharp edges | Excellent | Cleanest possible paths; SVG usually <10 KB |
| Multi-colour flat illustration | Very good | Each colour becomes its own path; expect a slightly larger SVG |
| Scanned line art, black on white | Good | Lower the precision and use a thresholded scan for fewer stray nodes |
| Icons with anti-aliased edges | Good | Anti-aliasing produces faint "halo" paths; flatten or upsample first |
| Text rendered as pixels | Fair | Traces as outlined shapes, not text — not searchable or restyleable; OCR first if you need real text |
| Photographs and gradients | Poor | Vector tracing isn't designed for tonal images; keep photos as JPG or use BMP to PNG for a lossless raster |
| Small/low-res BMP (<200 px) | Variable | Upsample to 500-1000 px first so the tracer has enough edge data |
| Precision | Behaviour | Pick when |
|---|---|---|
| 1-2 | Coordinates rounded hard; nodes snap to a coarse grid | You need the smallest possible SVG and the artwork has only straight edges |
| 3-4 | Visible smoothing of curves, file shrinks noticeably | Inline data-URI SVGs where every byte counts (favicons, email signatures) |
| 5-6 (default) | Balanced — paths stay smooth, file stays small | Most logos, icons, and illustrations |
| 7-8 | Curves preserved to sub-pixel accuracy | Decorative artwork that will be scaled large in print |
| 9-10 | Maximum fidelity; file size grows | Engraving / cutting workflows where path accuracy maps 1:1 to tool travel |
Almost never. Vector tracers work by clustering same-colour regions and drawing outlines around them — a photograph has thousands of continuous tonal transitions, so the tracer either produces a posterised "paint-by-numbers" approximation or an enormous SVG full of micro-paths. For photos, keep the raster: BMP to PNG for lossless or BMP to JPG for the smallest file.
The trace is genuine vector geometry — you're almost certainly looking at the preview in an image viewer that's rendering it at a fixed resolution. Open the SVG in a browser, Inkscape, or Illustrator and zoom in there; the paths stay sharp at any zoom. If the trace itself shows visible "stair-stepping" in a vector editor, raise the precision slider to 7-8 and re-convert.
Yes. SVG is plain XML — open it in any text editor to tweak fill, stroke, or path data, or drop it into Inkscape (free), Adobe Illustrator, Figma, Affinity Designer, or Sketch. You can also restyle colours from CSS when the SVG is inlined into a webpage, which a BMP never permits.
Only if the source BMP is a 32-bit BMP with a real alpha channel (BITMAPV4HEADER or later — most BMPs in the wild are 24-bit and have none). Where alpha is missing, the tracer treats the existing background as another colour region. For best results pre-process in an editor: knock out the background to true transparent, save as 32-bit BMP or convert to PNG first, then trace.
Two-colour logos routinely shrink 90-95% (a 500 KB BMP → 25 KB SVG). Multi-colour illustrations land around 70-85%. Photos grow on conversion, which is one more reason not to trace them. Gzipping the SVG (or saving as .svgz) trims another ~70% on top.
For logos, icons, UI glyphs, and flat illustrations — yes. SVGs scale to any DPR, can be styled with CSS (changing colour by class, hover state, dark mode), and are usually smaller than equivalent PNG@2x assets. For photographs or screenshots, stick with PNG, JPG, or WebP — see SVG to PNG if you ever need to flip back.
Yes, with caveats. Cricut Design Space, Silhouette Studio, and Glowforge all import SVG natively. Cutters expect closed paths with clear fills, so very low precision (1-2) can leave gaps and very high precision (9-10) can produce micro-segments that confuse path planning. Stick to 4-6 unless you're seeing specific cut-quality issues, and ungroup/clean up stray nodes in the design app before sending to the machine.
Yes, and it's the most common cause of "noisy" SVG output from BMPs. Anti-aliasing introduces dozens of edge-pixel colours that the tracer treats as their own regions, producing tiny halo paths around every shape. Pre-process the BMP in an image editor: threshold or posterise to flatten near-identical colours, or upscale the image 2-3× and trace from there so the AA pixels become an insignificant fraction of each region.
The conversion runs in your browser session — there's no upload cap to a server. Practical ceilings are set by your device's memory; very large BMPs (50+ MP) can take a while to trace because every pixel goes through edge detection. For workflows with thousands of files, batch them in groups of 20-50.