Why Your Auto-Traced SVG Has Too Many Nodes

You open the SVG your tracer just produced, click a curve that should have four points, and the selection fills with hundreds of them. The file is 85 KB. It looks correct — which is the confusing part — but it is unusable for editing.

This is the most common complaint about automatic tracing, and the usual advice ("run Simplify", "reduce the detail slider") treats the symptom. Here is what we found when we actually measured it.

We built the measuring tool first

Every previous attempt we made at this was graded by eye, which is why "this is fixed" and "this is still bad" managed to coexist for months. So before changing anything we built an answer key.

The method: take hand-authored logo SVGs, where a human decided exactly how many points each curve needs. Render them to raster. Trace the raster. Then grade the result against the SVG it came from.

That last part matters. Almost all tracing comparisons grade output against the image, which can only tell you whether the pixels match. It cannot tell you whether the geometry is sane, because a shape traced with 900 points and the same shape traced with 9 both match the pixels.

The result was not what we expected

	Median
Shapes, vs the source SVG	2.4x too many
Nodes, vs the source SVG	36.6x too many
Mean pixel error	0.22%

Two things fall out of this, and both redirected the work.

Accuracy was never the problem. 0.22% error means the output already looked right. Every hour we had spent on colour accuracy and edge handling was attacking something largely solved.

The problem is economy, and it is almost entirely nodes-per-shape. Segmentation was finding roughly the right regions — 2.4x is not nothing, but it is the right order of magnitude. The geometry describing those regions was 36x denser than it needed to be.

Why tracers do this

A tracer walks the boundary between two colours and fits curve segments to it as it goes. Working locally and greedily, it emits control points in proportion to the length of the boundary. Nothing in that process is trying to use fewer points, because nothing in that process knows what the shape is.

The tell is what happens when you give it a better image. We measured 36.6x excess on clean renders and only 18.8x on degraded, compressed ones. A higher-resolution input traces worse, because there is more pixel staircase to follow faithfully. That is the signature of a process tracking pixels rather than describing a shape.

Redundancy, or genuine noise?

This was the question that decided whether the problem was fixable.

If the boundary itself is noisy — genuinely wobbling in and out by a pixel — then the nodes are carrying real information about a messy edge, and removing them costs accuracy. If the boundary is fine and merely described wastefully, the nodes are free to remove.

So we re-fitted the existing output with a tolerance-driven fitter and re-measured:

36.6x → 2.6x, at unchanged pixel error.

Overwhelmingly redundancy. And note where 2.6x lands — almost exactly the 2.4x shape excess, which means that once the geometry is refitted, nodes-per-shape is essentially correct. The remaining excess is regions, not points.

What actually fixes it

Three things, in order of how much they contributed:

Fit to a tolerance, not to the pixels. Instead of following the boundary, choose the fewest cubic segments that stay within a quarter-pixel of it. This is the 10x on its own. Loosen it much past that and the shape visibly deforms — we measured drift starting around 0.6px.

Find the corners first, and pin them. Smoothing or refitting across a corner rounds it into a fillet. Corner detection turns out to need a wide window, because the tracer has already rounded its own corners over several points, so no single point turns sharply enough to register. It also needs a way to tell a corner from a curve: on a circular arc, turning accumulates as you widen the window; at a corner it stays flat. Without that test, lowering the threshold enough to catch the shallow corners in italic letterforms starts pinning the middle of a swoosh.

Recognise the primitives. A traced circle is never round, because the pixel grid is square. Detecting that a boundary is a circle and emitting four points is a large win on logos, which are full of dots and rings.

One trap worth naming, because it cost us a whole logo during development: accepting a circle on how closely the points sit at a constant radius is not enough. A thin arc, a crescent, and a baseball seam all have near-constant radius. You have to also check the enclosed area, or you replace an arc with a solid disc.

What it does to real files

Aggregate across the corpus, with the change forced off and then on:

• 3.2x fewer nodes, median
• 9.1x smaller, median
• 0.000pp change in mean pixel error
• 23 images: 23 fine, 0 regressions

Some individual results:

• A traced wordmark went from 174 paths to 6 — and the six are the mark's real structure: background, two letter groups, two swooshes, one dot. 85 KB to 3.2 KB.
• A six-colour sports crest: 14,853 nodes to 4,109. 912 KB to 112 KB.
• A low-poly illustration: 32,182 nodes to 6,094, with 63% of the output emitted as exact straight lines rather than curves. 2,157 KB to 156 KB.

The fidelity number is the one to sit with. Removing 36x the necessary nodes cost nothing measurable in accuracy. They were never carrying detail.

Why it matters beyond file size

Editing. Dragging one point of a four-point curve reshapes it. Dragging one point of a four-hundred-point curve makes a dent.

Cutting machines. Cricut Design Space refuses any SVG over 5,000 paths outright. Dense geometry is also a common cause of a cut that stutters, because the machine is being asked to change direction thousands of times along what should be a smooth arc.

Page weight. A 3.2 KB logo and an 85 KB logo render identically. One of them is 26x more of your performance budget.

Try it on your own file

Drop a PNG or JPG in and look at the path count in the output. Tracing runs entirely in your browser — the image never leaves your machine, and there is no sign-up to trace or preview.

Everything above is reproducible: the grading harness, the corpus, and the measurement scripts are in the repository, and the numbers in this post came from running them rather than from an estimate.