Should you upscale before vectorizing?

A gap can return—and still be wrong

Every image below is shown on the same 384 × 384 canvas. Compare the white gap, the dot’s color and the navy corners. The first tile is the reference; the other four are actual SVG renders.

What the extra pixels cost

The 96 px original lost the sampled gap; both enlargements retained all 435 checked white pixels inside it. That did not restore the dot’s coral color. Paths count separate SVG path elements, including the background. Bytes are the downloadable SVG file size.

Source: /examples/upscale-before-vectorizing/results.json

A simple logo may not benefit

We repeated the same four variants without the small dot and narrow gap. Enlarging this control added complexity without a clear improvement. It keeps the test from depending only on details that a small trace loses.

More pixels, more file

Without tiny details to recover, nearest-neighbor added nodes without improving the measured RGB error. Lanczos added edge contours and a much larger SVG. File size alone does not tell you which trace looks better.

Source: /examples/upscale-before-vectorizing/results.json

What these examples do—and do not—show

• A recovered shape can still be inaccurate

  The original small trace loses the dot. The other three return a dot, but none preserves its coral color—not even the trace of the native 384 px source. Check color and shape, not just whether something is present.

• Automatic tracing changed too

  On the detailed example, the 96 px input used polygon tracing; all three larger inputs used spline tracing. On the simple control, only Lanczos switched to splines. The difference belongs to the whole pipeline; this test does not isolate resampling as its cause.

• This is a local experiment

  These eight traces came from a local command-line run with the same settings. It bypassed the website’s browser preprocessing and hosted API. Two synthetic designs are not a representative sample of customer artwork. Hosted results may differ.

• This was not an AI-upscaler test

  Nearest-neighbor and Lanczos resized existing pixels. The native reference was drawn from the original geometry. No AI upscaler was used or evaluated.

Is ordinary resizing the same as AI upscaling?

No. Ordinary resizing, including nearest-neighbor and Lanczos, calculates enlarged pixels from the existing image. Learned restoration methods such as Real-ESRGAN use a trained model instead.

• Keep the evidence separate

  The comparisons here test only ordinary resizing, so they cannot establish whether an AI upscaler would improve your trace. If you test one, compare its traced output against trusted artwork for thin lines, gaps, shapes and colors; sharper appearance alone is not an acceptance test.

A small comparison beats a fixed 4× rule

1. 1. Look for the original first

   Ask for the original vector or a genuinely higher-resolution export. An enlarged copy of the same small image is not that source.

2. 2. Trace the untouched image

   Keep it as your baseline. Check thin gaps, small marks, rounded corners and intended colors at the size you will use.

3. 3. Test one enlargement if a feature is missing

   Keep a separate copy and compare its SVG with the baseline. Our examples used 4× nearest-neighbor and 4× Lanczos; that is a test setup, not a recommended factor for every image.

4. 4. Keep the result that preserves the artwork

   Reject an apparent improvement if it changes colors, adds unwanted outlines or makes edges worse. If neither trace is usable, obtain a better source or redraw the affected parts. Reducing SVG nodes is a separate cleanup decision.

How we made the comparison

Research date

30 October 2026

Environment

The native artwork was drawn at 1536 px and reduced to 384 px for antialiasing. The small input was reduced to 96 px. Nearest-neighbor and Lanczos copies were enlarged from that 96 px input to 384 px. Each opaque PNG was traced locally with Balanced, automatic mode, a 600,000-pixel area limit, a 3072-pixel width limit and color precision 8. None reached the area or width limit.

Sample size

Two self-authored synthetic designs; four inputs per design. Eight SVG traces, each rendered at 384 × 384 for comparison.

Tool versions

Pillow 12.3.0; installed vtracer package 0.6.15; CairoSVG 2.9.1. Generated SVG comments say ‘visioncortex VTracer 0.6.12’. We retain that output metadata and report the installed package separately.

Metrics defined

Paths: SVG path elements. Bytes: UTF-8 SVG size with LF line endings. The audit also records node counts, RGB error, foreground overlap and fixed dot/gap pixel checks. These diagnostics are not perceptual-quality rankings; inspect the pictures alongside them.

Not tested by this run

Hosted uploads, browser preprocessing, AI upscalers, typical customer artwork, physical cutting and downstream design-software import behavior.

Known variance

The automatic polygon/spline choice changes across some inputs, so the effects of interpolation and tracing mode are not separated. Different software versions or hosted preprocessing may change outputs.

Download the evidence

• Check the pictures and numbers

  The audit ZIP contains both reference images, all eight input PNGs, generated SVGs, renders, recorded results and a portable audit script. Every figure above also links its individual files.

• What the audit reproduces

  The README explains how to regenerate the synthetic references, recount paths and bytes, recompute the saved-render measurements and optionally render the SVGs again. It audits the measured table; it does not reproduce the private tracing pipeline. No private engine source or original tracing logs are included.

Start with your original image

• Make your own comparison

  Use the PNG to SVG converter with your original first. Check its result before making an enlarged copy. The website’s output is not promised to match this local experiment. For preparing a logo source, see logo to vector.