Your 'vectorized' SVG may still be a bitmap — 4 checks, with measurements

When you "vectorize" an image, the result is supposed to be paths — geometry you can scale, recolor, and cut. A surprising number of tools, including Inkscape's own Trace Bitmap, instead wrap the original bitmap in an <svg> tag, so the file is a picture inside a vector wrapper. It looks fine at 100% and falls apart everywhere else.

You can tell which one you got in about a minute. Here are four checks, then the numbers from a benchmark I ran.

Check 1 — count the <image> elements

Open the SVG in a text editor and search for <image.

A non-zero count means a raster picture is embedded, and the file is at least partly a bitmap in a vector wrapper. Zero is a good sign, but not the whole story (see check 3).

Check 2 — compare bytes with and without the bitmap

Strip every <image> element and compare the file sizes. The delta is exactly how many bytes of picture were hiding inside.

# bytes with the embedded bitmap removed
python3 - <<'EOF'
import re
s = open("out.svg").read()
print(len(s.encode()), "->", len(re.sub(r"<image\b.*?</image>|<image\b[^>]*/>", "", s).encode()))
EOF

If the file drops by 70% when you remove the image, the image was the artwork.

Check 3 — is the visible shape actually made of paths?

Path count is the giveaway. If the artwork you see has rich color but the <svg> contains 4 <path> elements, those paths are not drawing your picture — the embedded bitmap is.

Check 4 — render it huge

Rasterize the SVG at 20× and zoom in. Real vector paths hold a clean edge; an embedded bitmap goes soft and pixelated the moment you pass the source resolution.

What the measurement actually showed

I ran three tracers on three inputs on one Apple-silicon Mac, twice each on two dates (2026-09-28 and 2026-09-29). The harness recorded offline: true — not one call left the machine. Two inputs kept identical SHA-256 hashes across both runs and produced byte-identical Inkscape and potrace output, so the columns below are reproducible.

Three things fall out of this:

1. Inkscape's stock Trace Bitmap exported exactly one embedded <image> every time — all three inputs, both dates. The bare <image> count is not a perfect verdict on its own, but here it fired on every single run.
2. potrace is honest but 1-bit. It never embeds a bitmap, and it never produces more than one colour layer. Perfect for a stencil, useless for a logo.
3. Path count tracks "is this really a vector". The icon that came out as 3 paths and the photo-derived banner that came out as 236 paths are genuinely editable; the 7-path Inkscape file is a 20 KB bitmap with a thin vector coat of paint.

Why this bites harder than it looks

• CNC, laser, and vinyl cutters consume the paths, not the pixels. A raster-in-a-wrapper produces a toolpath around the image bounds, not the shape you wanted.
• Web use means shipping a 550 KB "SVG" that could have been 30 KB, then watching it blur on a retina display.
• Editing is the loudest tell: try to recolor a single region of an embedded bitmap inside a vector editor. You can't, because there is no path there to select.

Getting a real one

If you'd rather generate than audit: potrace is the right tool for flat, high-contrast art. For photos, logos, and multi-colour artwork you want a colour tracer that emits genuine filled paths.

Full disclosure: I build one — pic2svg, the engine in the table above. It's a hosted tracer (image posted to the API, traced there), free to trace and preview, with a paid tier for downloads. But the point of this post is the checklist, not the pitch: run checks 1–4 on whatever tool you already use, and you'll know in a minute whether you're holding vectors or a picture in a costume.

The raw measurements and the exact commands are published at pic2svg.com/offline-vector-converter-benchmark if you want to reproduce or dispute them.