Convexy

Can you convert a photo (JPG or PNG) to SVG?

No — not in the sense you mean. A photo contains no vectors, so there are none to recover. What every tool advertising "JPG to SVG" actually does is trace the image: reduce it to a handful of flat colours, find the boundaries between them, and approximate those boundaries with paths. That works decently on a logo and badly on a photograph. And a depressing number of converters do something worse than that, which you can catch in ten seconds once you know the trick.

Why the answer is no

The two kinds of image are not two encodings of the same thing. They differ in kind.

A raster — JPG, PNG, HEIC, anything from a camera — is a grid of coloured pixels. A 12-megapixel photo is twelve million colour measurements and nothing else. There is no "edge" recorded anywhere in it, and no "shape". Your eye assembles those from the pixels; the file does not contain them.

A vector — SVG — is a set of instructions. Fill this Bézier path with this red. Stroke that circle 2 units wide. It describes geometry, which is why it stays sharp at any size: the renderer re-draws it from the maths at whatever resolution you ask for.

Going from vector to raster is easy — execute the instructions, record the result. Going the other way means inventing instructions that were never there, by inspecting the pixels and guessing what shapes might have produced them. That guess is a trace. It is an approximation, and calling it a conversion is the original sin of this whole category.

What a tracer actually does

The real algorithms are decades old and follow roughly four steps:

  1. Quantise the colours — reduce the image from millions of colours to a small palette, say 8 or 32. Everything similar collapses into one flat colour.
  2. Find the regions. Each palette colour now forms blobs. Walk the boundary of every blob and you get its exact staircase outline.
  3. Simplify. That staircase has thousands of points. Discard the ones that barely change the shape, keeping the corners.
  4. Smooth. Round what is left into curves, so the output does not look drawn on graph paper.

The result is a genuine SVG full of real <path> elements — scalable, editable, and not your image. It is a flat-colour cartoon of your image, and how good a cartoon depends entirely on what you fed it.

What traces well, and what does not

Traces well: logos, icons, line art, signatures, silhouettes, black-and-white scans, flat illustrations, charts. Anything that was flat shapes and hard edges before it became pixels — you are reconstructing something that genuinely had a vector nature, and the result can be excellent.

Traces badly: photographs. All of them. A face is a continuous gradient of subtly varying tones with no hard edges anywhere. Force it into 12 flat colours and you get a posterised, blotchy, Warhol-ish thing — occasionally an interesting effect, never a faithful reproduction. Raise the palette to keep the detail and you get an SVG of tens of thousands of paths that is slower to render and larger than the JPEG you started with, and still does not look like the photo.

That is not a limitation of any particular tracer. It is what happens when you approximate continuous tone with flat regions. There is no version of this that works.

The dishonest trick. Because real tracing is hard and photos trace badly, a lot of converters skip it entirely and emit this:

<svg><image href="data:image/png;base64,iVBORw0KGgo..."/></svg>

That is your bitmap, base64-encoded, wrapped in an SVG tag. It is a file with an .svg extension containing exactly the pixels you started with. It does not scale — zoom in and it blurs like any JPEG. It is about a third larger than the original, because base64 encoding adds roughly 33% overhead. It will be rejected by anything that actually needs a vector: a cutting machine, an embroidery digitiser, a sign printer, a proper design tool.

It is a bitmap in a costume, and it passes a superficial glance because the file really does end in .svg.

How to check any SVG in ten seconds

This works on output from any tool, ours included, and you should use it.

Open the .svg in a text editor. An SVG is plain text — that is the point of it. Any text editor will do; on iPhone, rename the file to .txt and open it in Files, or drop it into any notes app.

Then look:

The other test is simpler still: zoom in hard. A real vector stays crisp forever. A fake one turns to mush, because it is pixels.

If you actually need a real vector

Tracing is the wrong tool for a job that has a right one:

None of these recovers anything from the photo. There is nothing in the photo to recover. That is the point.

What Convexy does. It offers Trace to SVG, and calls it a trace, because that is what it is. It emits real <path> geometry — there is no <image> element, no data: URI and no base64 anywhere in its output, and a test fails the build if that ever changes. You can control the palette size, how aggressively contours are simplified, and how much curve smoothing is applied. It will still make a mess of a photograph, because everything does.

Common questions

Can you convert a JPG or PNG photo to SVG?

Not in any real sense. A photo is a grid of pixels and contains no vector shapes, so there is nothing to convert. Tools that claim to do it are tracing: quantising the image to a few flat colours and approximating the boundaries with paths. On a logo that works well. On a photograph it produces a posterised approximation, not your photo.

How do I tell if an SVG is a real vector or a fake?

Open it in a text editor — SVG is plain text. If you see an <image> tag, a data: URI, or a long base64 blob, it is a bitmap wrapped in an SVG file and it will not scale. If you see many <path d="..."> elements, it is genuine vector geometry. You can also just zoom in hard: a real vector stays sharp, a fake one blurs.

Why is my converted SVG bigger than the original JPG?

One of two reasons. Either the tool embedded your bitmap as base64 inside the SVG, which adds about 33% overhead and gives you nothing, or it produced a genuine trace of a photograph with tens of thousands of paths, which is a lot of text. Both mean the SVG is the wrong format for that image.

Why does my traced photo look posterised and blotchy?

Because that is what tracing does. It reduces the image to a small palette of flat colours and draws the boundaries between them. A photograph is continuous tone with no hard edges, so flattening it into regions destroys exactly the thing that made it look like a photo. No tracer avoids this — it is inherent to the approach, not a setting you got wrong.

Can AI vectorise a photo properly?

AI tracers produce better traces — cleaner curves, smarter region detection, fewer stray paths. They do not recover vectors, because there were never any vectors in the photo. A better approximation is still an approximation, and where an AI tool appears to add detail, it is inventing plausible detail rather than recovering real detail. For logos this is often good enough. For photographs it does not change the answer.

What is the best way to get a logo as an SVG?

Get the original file from whoever designed it — the .ai, .eps or .svg it was drawn in. That is the real vector, and it beats any trace. Failing that, redraw it in Illustrator, Affinity Designer, Figma or the free Inkscape; for a simple logo that is often a twenty-minute job. Auto-tracing and then cleaning up the paths by hand is the standard professional compromise.