SVGs are vector graphics that most design tools and browsers render natively, but plenty of places still expect a plain raster image (app store listings, older CMS uploads, email clients, and some social platforms all want a PNG). Converting rasterizes your vector at a fixed resolution, so if you need large output (a print-ready logo, for instance), make sure the SVG's source dimensions are big enough first. Scaling up a rasterized PNG afterward will blur it.
A one-way door from maths to pixels
An SVG describes shapes: this path, that fill, this stroke width. It has no inherent size, which is why the same file renders crisply on a watch face and a billboard. A PNG is a fixed grid of pixels. Converting from one to the other means committing, permanently, to a single resolution.
So the export size is the only decision that really matters here, and it is worth choosing deliberately rather than accepting whatever the default is. Export at the largest size the image will ever be displayed at, and ideally at twice that for high-density screens, because scaling the PNG up afterwards will only soften it.
When a raster version is the right answer
Plenty of places still cannot take an SVG. Email clients strip it or refuse to render it, since an SVG can carry script. GitHub READMEs render it inconsistently depending on where the file is hosted. Open Graph and Twitter card previews require a raster image. Some print workflows and older office software want pixels. In all of those cases a PNG export is not a downgrade, it is the format the destination actually accepts.
One thing to check in the result: text. If the SVG references a font by name rather than converting the letterforms to outlines, whatever renders the file has to have that font available, and if it does not, the substitute will change your layout. If the text looks wrong in the PNG, outline it in your design tool and export again.