The SVG format

What an SVG actually is

Open one in a text editor and you find XML: a <path> with a string of coordinates, a <circle>, a <text> element with real text inside it. Scalable Vector Graphics became a W3C recommendation in 2001, after the working group merged two competing submissions — Adobe’s PGML and Microsoft’s VML — into a single specification that neither company had proposed on its own.

Because the file is markup, it behaves like source code rather than like an asset. It diffs sensibly in version control, it can be edited by hand or generated by a script, and it is the only format on this site you can usefully grep.

What it is good at, and where it stops

Vectors are the right answer for logos, icons, diagrams, charts and line art: anything built from flat colour and hard edges. One file serves every screen density and every zoom level, because the shapes are re-drawn at whatever resolution is asked for rather than resampled. Text stays text, so it can be selected, searched and read by a screen reader. For that kind of artwork an SVG is usually smaller than the set of PNGs it replaces.

It stops at photographs. There is no sensible way to describe a photograph as shapes, so an SVG “of” a photo is almost always a base64-encoded JPEG wrapped in a few lines of XML — bigger than the JPEG, with none of the advantages of either.

Rasterising is one-way by nature

Drawing an SVG produces pixels, and pixels do not remember the instructions that produced them. This is not a limitation of this tool or of any other; it is what the operation is. Auto-tracing exists and it approximates: a twenty-path logo comes back as several hundred curves that nearly match the raster, larger than the original file and unpleasant to edit. It does not recover the artwork, it re-guesses it.

That is why this site converts out of SVG and never into it. There is no honest PNG-to-SVG, only a PNG-to-something-that-resembles-SVG, and calling it a conversion would be a misdescription.

How this tool draws one

Every other format here is decoded inside a Web Worker. SVG cannot be, because createImageBitmap rejects SVG blobs in both Chrome and Safari — so a vector is rasterised on the main thread instead, by loading the markup into an image element and letting the browser’s own renderer do the work. It is then handed to the worker as pixels, and the rest of the pipeline is identical.

Loading it that way has a useful side effect. An image element fed from a blob URL runs no script and fetches no subresources, so a hostile SVG has nothing to reach for — and equally, a well-meaning one cannot pull in a webfont it depends on.

The other thing a vector needs is a decision about resolution, since it has none of its own. A file that declares a width and a height is drawn at that size; a file with only a viewBox is drawn at 1024 px on its long edge. Setting a maximum width renders the vector at that size directly, so the edges stay crisp instead of being enlarged from a smaller draw.

What to convert it to

PNG for almost everything. Lossless, transparent where the source was, and hard edges stay hard. Decide the pixel size deliberately — that decision is the entire conversion.

WebP where the destination is a web page and the file size matters more than the last decade of software compatibility.

JPG rarely. It has no transparency, and its compression puts visible ringing along exactly the sharp edges that made the artwork worth drawing as vectors.

Whatever you export, keep the SVG. The raster is a derivative made for one size; the vector remains the master.