What size should I convert my SVG to?

Work back from where it is going, then double it if the screen it lands on might be high-density. A logo shown at 200px wide on a website should be exported at 400px; an app icon should be exported at the exact size the store specifies, with no doubling, because that specification already accounts for density. For print, multiply the physical width in inches by the target dpi - 5cm at 300dpi is 1.97 x 300, or about 590 pixels. The one size to avoid is whatever the file happens to report by default, because for an icon with only a viewBox that number is 150 pixels and has nothing to do with your use.

Why is my converted PNG blurry when the SVG looks perfect?

Because the rasterising happened at a smaller size than the one you are viewing it at. Either the file was rendered at its default size and enlarged afterwards - stretching pixels that were never drawn - or it was rendered at 1x and is being displayed on a high-density screen, which effectively does the same enlargement in the browser. The cure is the same in both cases: re-render from the SVG at the final pixel size, or at twice the display size for screens. Nothing done to the PNG afterwards will recover the detail, because the detail was never rasterised.

Can I convert a PNG back into an SVG?

Not in any meaningful sense. Going from SVG to PNG throws away the drawing instructions and keeps only the result, and no tool can reconstruct the original curves from the pixels. What auto-tracing software does instead is draw new outlines around regions of similar colour, which gives a vector file of a sort - usually with far more nodes than a hand-drawn one, visibly faceted curves, and no relationship to the layers the designer had. For a logo it is always worth finding the original SVG rather than tracing a PNG of it. Keep the SVG as your master copy for exactly this reason.

How to Convert SVG to PNG

An SVG is not a picture. It is a set of drawing instructions - move here, draw a curve, fill it with this colour - with no pixels until something renders it. A PNG is the opposite: a fixed grid of pixels and nothing else. Converting one to the other is less a format change than a decision about resolution, and that decision is the difference between a crisp export and a blurry one. Here is how to make it deliberately, in the SVG to PNG converter or on the command line.

Why your SVG has no natural size

Open the file in a text editor and look at the first tag. One of four situations applies, and which one decides what a converter can do:

Width and height in pixels - <svg width="800" height="600">. A real intrinsic size; the easy case.
Width and height in physical units - width="10cm", height="72pt", as Illustrator and Inkscape emit. These resolve to definite pixel sizes at 96 pixels per inch (10cm is 378px, 72pt is 96px), but a converter that reads the number and ignores the unit hands you a 10-pixel-wide image.
Only a viewBox - <svg viewBox="0 0 24 24">, no width or height. Very common for icons out of Figma: the file has a shape but no size.
Neither - no width, no height, no viewBox. Usually markup copied out of an HTML page.

The third case causes most bad conversions. Meeting an image with no intrinsic size, a browser falls back to the CSS default object size of 300x150 pixels and fits the drawing inside it, so a square icon renders at 150x150. That is not a browser bug - it is what the specification says to do - but a converter that simply asks the file how big it is gets told 150x150 about artwork whose author was thinking in 24x24. A 2x export from there is a 300px image built from a 150px render.

The converter here reads the viewBox instead and treats its units as the authored size, so a 24x24 icon is reported as 24x24 - and it names the rule it used.

Choose the pixel size before you render, never after

Because an SVG is instructions, it renders at 16 pixels or 4,000 with identical sharpness - but only if the renderer is told the target size up front. Rendering at 100px and enlarging the PNG to 400px afterwards invents three pixels for every real one, and no sharpening recovers an edge that was never drawn.

Drop the file into the SVG to PNG converter. It is read as text in your browser, so nothing is uploaded.
Check the detected size and the note saying where it came from: width and height attributes, viewBox, or a fallback because the file has neither.
Set the output size - a scale chip (1x to 8x) for a clean multiple, or an exact width, with the locked ratio filling in the height.
Pick format and background - PNG on transparent is the default - then convert and download. The preview sits on a checkerboard, so transparency is visible rather than assumed.

A worked example: one logo, two exports

Say the file is a wordmark starting <svg viewBox="0 0 160 40"> with no width or height: detected size 160x40, ratio 4:1. Two jobs, two answers:

Email signature shown at 160px wide: export at 2x - 320x80 - and set the display width to 160. Mail is read on high-density screens, where 1x looks soft.
Open Graph image, which wants 1200x630: type 1200 and the locked ratio gives 300, since 1200 divided by 4 is 300. Right shape for the logo, wrong shape for the slot - so unlock the ratio, set 1200x630, and the wordmark is centred with the spare space filled by your background colour. Padded, not stretched, and the tool says so.

A square icon is simpler: a 24x24 viewBox at 8x is 192x192, and typing 512 gives the 512x512 an app store asks for. The number you type is the number of pixels drawn.

The viewBox trap when you scale up

A quieter failure bites anyone doing this by hand. If an SVG has width and height but no viewBox, its coordinates are pinned one-to-one to pixels: editing width="100" to width="400" enlarges the canvas, not the drawing, which stays in the top-left corner. Add a viewBox matching the original size (viewBox="0 0 100 50") before changing the width and the drawing has a coordinate system to scale against. The converter does this automatically and says so; in a build script, do it yourself.

Transparency, and when JPG is the wrong answer

PNG and WebP carry an alpha channel, so anything the SVG does not paint stays genuinely transparent. JPG has none - a property of the format, not of any tool - so those areas must be filled, and a conversion that does not think about it fills them with black. That is why logos exported to JPG so often arrive on a dark rectangle. Choose the background deliberately, or choose PNG.

JPG compression is also built for photographs: it discards high-frequency detail, which is exactly what a logo's hard edges and flat colour are made of, producing the speckled halo around lettering that gives a JPG'd logo away. PNG stores flat colour losslessly and is usually the smaller file here - see PNG vs JPG vs WebP.

What does not survive the conversion

A browser rendering an SVG as an image sandboxes it. Three consequences worth knowing before blaming the converter:

Webfonts are not downloaded. Text falls back to a font on your device, and to a different one on someone else's. Convert text to outlines before exporting and the letterforms become ordinary shapes that render identically everywhere.
External references are not fetched: a linked image or stylesheet inside the SVG is ignored, though anything embedded as a data URI works normally.
Scripts, animation and interactivity are gone by definition: you get the first frame, and links and hover states belong to a document, not a grid of pixels.

If the output is blank, the usual cause is a missing xmlns="http://www.w3.org/2000/svg" on the root tag: without it the markup parses as generic XML and renders nothing. Common in SVG copied out of an HTML page, where the namespace is implied - the converter adds it when missing.

Doing it from the command line

For build scripts, rsvg-convert -w 512 logo.svg -o logo.png is the one to reach for: librsvg takes the target width directly. inkscape --export-type=png --export-width=512 logo.svg is slower but uses the editor's own renderer. ImageMagick works too, with a caveat - it delegates to librsvg or Inkscape when installed and falls back to a limited internal renderer when not, and -density must precede the input file. Its default of 72 is why plain magick logo.svg logo.png is small and soft.

When not to convert at all

On the web, keep the SVG: it is smaller, stays sharp at every zoom level without exporting a set of sizes, and can be styled with CSS. Convert when the destination cannot take vectors - email clients, Open Graph images, app store uploads, print, older Office documents. Render once at the size you need in the SVG to PNG converter and keep the SVG as the master.

Frequently asked questions

What size should I convert my SVG to?: Work back from where it is going, then double it if the screen it lands on might be high-density. A logo shown at 200px wide on a website should be exported at 400px; an app icon should be exported at the exact size the store specifies, with no doubling, because that specification already accounts for density. For print, multiply the physical width in inches by the target dpi - 5cm at 300dpi is 1.97 x 300, or about 590 pixels. The one size to avoid is whatever the file happens to report by default, because for an icon with only a viewBox that number is 150 pixels and has nothing to do with your use.
Why is my converted PNG blurry when the SVG looks perfect?: Because the rasterising happened at a smaller size than the one you are viewing it at. Either the file was rendered at its default size and enlarged afterwards - stretching pixels that were never drawn - or it was rendered at 1x and is being displayed on a high-density screen, which effectively does the same enlargement in the browser. The cure is the same in both cases: re-render from the SVG at the final pixel size, or at twice the display size for screens. Nothing done to the PNG afterwards will recover the detail, because the detail was never rasterised.
Can I convert a PNG back into an SVG?: Not in any meaningful sense. Going from SVG to PNG throws away the drawing instructions and keeps only the result, and no tool can reconstruct the original curves from the pixels. What auto-tracing software does instead is draw new outlines around regions of similar colour, which gives a vector file of a sort - usually with far more nodes than a hand-drawn one, visibly faceted curves, and no relationship to the layers the designer had. For a logo it is always worth finding the original SVG rather than tracing a PNG of it. Keep the SVG as your master copy for exactly this reason.