I Built a Browser-Only Image Vectorizer with WebAssembly

Most online image vectorizers have the same uncomfortable tradeoff: upload your file, wait for a server to process it, then hope the SVG export is not locked behind a paywall or covered with a watermark.

That feels especially wrong for the common cases I care about:

• A designer has a client's logo as a low-resolution PNG.
• A developer needs a quick SVG icon from a raster asset.
• A maker wants a clean SVG for Cricut, laser cutting, or print-on-demand.
• Someone has a signature, sketch, or line drawing that should never touch a random server.

So I built Vectorize Image: a free image-to-SVG converter that runs entirely in the browser.

No upload. No account. No watermark. The input image stays on your device.

What it does

The tool takes a PNG, JPG, or WebP file and turns it into a downloadable SVG.

The first version is intentionally narrow:

• Upload PNG, JPG, or WebP up to 10 MB.
• Choose one of three presets: Logo, Sketch, or Photo.
• Preview the original and vector result side by side.
• Download the SVG.
• Keep the entire conversion local in the browser.

It is not trying to be a full Illustrator replacement. It does not edit individual nodes. It does not export DXF, PDF, or EPS yet. It does one job: raster image in, SVG out.

That constraint made the architecture much simpler.

The core idea: send the algorithm to the file

The normal approach for image conversion tools is:

browser -> upload image -> server processes image -> browser downloads result

I wanted the opposite:

browser downloads app once -> image is processed locally -> SVG is generated locally

That meant the vectorization engine had to run in the browser.

For tracing, I used the open-source vtracer algorithm. It is written in Rust and works well for the kinds of inputs this tool is designed for: logos, icons, sketches, line art, signatures, and flat illustrations.

The browser pipeline looks like this:

File input
  -> createImageBitmap()
  -> canvas / ImageData
  -> Web Worker
  -> vtracer compiled to WebAssembly
  -> SVG string
  -> preview + download

The important part is that the image bytes never need to leave the page.

Why WebAssembly

I looked at pure JavaScript tracing libraries, but quality and performance are difficult once you care about multi-color output. I also did not want the first version to require a backend queue, object storage, cleanup jobs, or file retention rules.

WebAssembly was a good fit:

• The tracing engine already exists in Rust.
• The compiled wasm package can be lazy-loaded only when the user uploads a file.
• The whole site can still be deployed as static files.
• Privacy is stronger because there is no upload endpoint.
• Hosting cost stays close to zero.

The app is a static Next.js site deployed on Cloudflare Pages. The wasm module is just another asset.

Why a Web Worker

Vector tracing can be expensive. A small flat logo may finish quickly, but a detailed photo can take much longer and produce a very large SVG.

Running that work on the main thread would make the UI feel broken. So the tracing happens inside a Web Worker.

The simplified worker shape looks like this:

import init, { convert } from "wasm-vtracer";
import { PRESET_PARAMS } from "../lib/vectorize.types";

let ready: Promise<unknown> | null = null;

function ensureReady() {
  if (!ready) ready = init();
  return ready;
}

self.addEventListener("message", async (event) => {
  const { imageData, preset } = event.data;
  const started = performance.now();

  try {
    await ensureReady();

    const rgba = new Uint8Array(
      imageData.data.buffer,
      imageData.data.byteOffset,
      imageData.data.byteLength
    );

    const svg = convert(
      rgba,
      imageData.width,
      imageData.height,
      PRESET_PARAMS[preset]
    );

    self.postMessage({
      ok: true,
      svg,
      ms: Math.round(performance.now() - started),
      bytes: new Blob([svg]).size,
    });
  } catch (error) {
    self.postMessage({
      ok: false,
      error: error instanceof Error ? error.message : String(error),
    });
  }
});

There is only one request and one response, so I kept the first implementation on native postMessage. If I add progress events or a richer API later, I may wrap it with Comlink.

Presets matter more than sliders

vtracer exposes a lot of useful parameters: color precision, speckle filtering, path precision, hierarchy mode, corner threshold, and more.

That is great for tuning, but it is not a great first-run user experience. Most users do not open a converter because they want to learn tracing parameters. They open it because they want an SVG.

So the MVP starts with three presets:

• Logo: flat-color marks, icons, brand assets.
• Sketch: signatures, hand drawings, line art.
• Photo: detailed or shaded images, with realistic expectations.

The biggest lesson from testing: the best user experience is not always exposing every control. It is picking good defaults and being honest about the boundaries.

The hard boundary: photos are not magic

Vector tracing is not the same as AI image reconstruction.

For logos, icons, signatures, and clean line art, the output can be very useful. The SVG is usually small, sharp, and easy to import into Figma, Illustrator, Inkscape, or a cutting workflow.

For detailed photographs, the result is different. A photo contains thousands of small color transitions, textures, shadows, and noise. A vector tracer has to approximate those pixels with shapes. That can produce:

• huge SVG files,
• too many paths,
• slow rendering,
• stylized output rather than a faithful photo.

So the UI warns users when an image looks too complex or the output is too heavy. The goal is not to pretend every photo becomes a perfect vector. The goal is to help people use the tool where vector tracing actually works.

That is why the homepage and tool copy emphasize logos, sketches, line art, signatures, and flat illustrations first.

The privacy benefit is also a product feature

"Your image never leaves your browser" is not just a privacy line. It changes what the product can be.

It means:

• no temporary image storage,
• no cleanup cron,
• no file retention policy to enforce,
• no backend scaling problem for free users,
• no need to handle uploaded customer logos on a server.

For a small utility product, that is a major operational win.

It also makes the product easier to explain. The browser downloads the code. Your image stays local. The SVG is generated locally. That is the whole model.

Current stack

The current version uses:

• Next.js with static export
• TypeScript
• Tailwind CSS
• Rust compiled to WebAssembly
• vtracer for raster-to-vector tracing
• Web Worker for off-main-thread processing
• Cloudflare Pages for hosting

Because there is no application server, the site is cheap to run and easy to cache. The heavy work happens on the user's device only after they choose a file.

What I would add next

The next improvements are not bigger infrastructure. They are small product upgrades:

• an advanced panel for color precision, speckle filtering, and path precision,
• better warnings for complex photos,
• more use-case pages for Cricut, signatures, sketches, and AI-generated icons,
• more before/after examples,
• possibly HEIC input if enough mobile users need it.

I am intentionally not rushing into accounts, payments, batch processing, or an API until the basic tool has enough real usage data.

Try it

You can try the tool here:

https://vectorize-image.app

It works best on logos, icons, signatures, sketches, line art, and flat illustrations.

If you test it with an image type that breaks badly, I would like to know. The most useful feedback right now is not "nice app", but "this kind of input produces ugly SVGs."