SVG to PNG converter

Why the same SVG exports at three different sizes

An SVG has no resolution. It is a description of shapes, and the question "how big is it?" has three possible answers depending on what the file happens to declare — which is exactly why the same logo can come out of three converters at three different pixel sizes, all of them technically defensible.

If the root tag carries width and height, those win. Note that they may be in physical units: width="10cm" is not 10 pixels, it is 378, because CSS fixes one inch at 96 pixels and every absolute unit derives from that. Converters that call parseInt on the attribute read that file as 10 pixels wide and produce a thumbnail the size of a full stop.

If width and height are missing but a viewBox is present — and this is the most common case by a wide margin, because it is what Figma, most icon libraries and every SVG designed to scale with CSS produce — the correct reading is the third and fourth numbers of the viewBox. A file with viewBox="0 0 640 480" has an intrinsic size of 640 × 480 even though it never says so. Tools that miss this either render a 0 × 0 canvas and hand you an empty PNG, or fall back to a default and hand you a crop.

If both are missing, the file genuinely has no intrinsic size, and the browser falls back to the CSS default for replaced elements: 300 × 150. That number is not a bug and not a guess by this tool — it is in the specification. When you see it, set an exact width instead and stop thinking about it.

Two smaller repairs happen automatically. A viewBox is injected when it is absent, because without one, changing width and height only enlarges the frame and leaves the drawing sitting in the corner at its original size. And an xmlns attribute is added when missing, which is the usual reason a hand-pasted snippet renders as nothing at all: without the namespace declaration the browser does not accept the markup as SVG, and it fails silently.

Scale is the entire reason to use a vector source

Rasterising an SVG at 1× is almost never what you want. The whole advantage of holding a vector master is that the export size is a decision made at export time, not a limit inherited from the file. A 2× export is not an upscale of a 1× export — it is a completely separate render at double the resolution, with genuinely sharper curves and text, not interpolated pixels.

The multipliers that matter in practice are these. 2× is the baseline for anything shown on a screen, because every phone and most laptops have been higher-than-1× density for over a decade; a 1× asset on a modern display is visibly soft. 3× and 4× cover high-density phones and the case where the same asset gets reused later at a size nobody predicted. 8× is for print and for source assets you want to downsample from — downsampling is lossless-looking, upsampling never is.

Fixed width is the other mode people actually need: an avatar slot wants 512 pixels regardless of what the source measures, and a header image wants 1600. Set the width and the height follows from the aspect ratio, computed from the resolved intrinsic size rather than from whatever the file claims. Exact size, where you pin both sides, is available and will distort the drawing if the ratio does not match — it is offered because sometimes a fixed-dimension slot is a hard requirement, but it is the one mode to reach for last.

Working out how many pixels print needs

A vector file has no DPI. DPI is a property of the output device, and the number only becomes meaningful when you decide the physical size the image will occupy. That is why "export at 300 DPI" is an incomplete instruction — 300 DPI at what size?

The arithmetic is one step: pixels = inches × DPI, or millimetres ÷ 25.4 × DPI. A logo printed 90 mm wide on a business card at 300 DPI needs 1063 pixels. A full-bleed A4 page at 210 mm needs 2480. A 2-metre roll-up banner, viewed from three metres away, is fine at 100 DPI, which is 7874 pixels — large, but far smaller than the 23,000 you would get by blindly applying 300.

The output line under the preview shows the physical size at 300 DPI for whatever dimensions you have chosen, so you can work backwards: adjust the multiplier until the centimetres match the size you are printing. And a caveat worth knowing before you send anything to a commercial printer: PNG is RGB. Presses are CMYK. Bright saturated colours, particularly oranges and vivid blues, shift when converted, and a printer that asks for vector artwork is asking because the vector can be colour-converted without any of this loss. Send the SVG or a PDF if they will take it.

Why the text vanished, or came back in the wrong font

This is the single most common complaint about SVG-to-PNG conversion anywhere, and the cause is always the same. Rasterisation does not fetch fonts. When an SVG is rendered as an image, the renderer runs in an isolated mode with no network access — a deliberate security boundary, not an oversight — so a @font-face pointing at Google Fonts, or a font-family naming a typeface installed only on the designer's machine, resolves to nothing.

What you get instead is a substitution. The letters are drawn in a fallback face with different metrics, so a wordmark that fitted its box now overflows it, tracking collapses, and a carefully kerned logotype turns into something the client will notice immediately. Occasionally nothing is drawn at all.

There are exactly two reliable fixes. Convert text to outlines before exporting the SVG — Type > Create Outlines in Illustrator, Outline Stroke in Figma, Path > Object to Path in Inkscape. The letters become shapes, no font is involved, and the render is byte-for-byte what you designed. Or embed the font in the SVG as a base64 data: URI inside the @font-face rule, which works but adds tens of kilobytes and may breach the font's licence.

This tool inspects the markup for live <text>, <tspan> and <textPath> elements, checks whether any font is embedded, and warns you when the combination is risky — listing the font names it found. A warning you can act on beats a plausible-looking PNG with the wrong typeface that you only discover after it has been printed.

Transparency, and the three places it breaks

PNG supports a full 8-bit alpha channel, so transparency survives conversion cleanly and transparent is the default here. The checkerboard behind the preview is there so you can verify it rather than assume it. Three things still go wrong.

• The background was never transparent. Plenty of SVGs contain a full-size white <rect> as the first element. Nothing in the conversion can remove it — the white is part of the drawing. Delete that rectangle in your editor and re-export.
• The destination flattens alpha. JPEG has no alpha channel at all, so anything transparent becomes black or white when converted onward. Many print workflows, some email clients and a number of older CMSes do the same. When you know the destination will flatten, pick the background colour here instead and control what it flattens to.
• Semi-transparent edges on a dark background. Antialiased edges are partially transparent pixels, and if they were rendered assuming a white background they carry a white fringe that shows up as a halo on a dark page. Exporting at 2× or more shrinks the fringe to something invisible, which is another quiet argument for never exporting at 1×.

SVG, PNG and WebP: when not to convert

Converting is a downgrade, and it is worth being deliberate about it. An SVG is a resolution-independent description: it is sharp at every zoom level and on every display density, it is usually smaller than the PNG for logos and icons, its individual parts can be recoloured or animated with CSS, and it is text, so it compresses well and diffs cleanly in version control.

A PNG is a fixed grid of pixels. It is sharp at exactly one size, it needs a separate file per density, and it cannot be restyled. What it has going for it is that everything on earth accepts it. So the rule is simple: convert when the destination cannot take a vector, and only then.

The destinations that genuinely require it are print shops and their preflight systems, most social platforms, email clients, embroidery and print-on-demand services, older content management systems, app icon pipelines that demand exact pixel dimensions, and any upload form that rejects .svg on principle — a common security measure, since an SVG is executable markup.

WebP is worth mentioning because it is frequently the better raster choice for the web: it supports alpha like PNG and typically lands 25–35% smaller on the same image. Its weakness is compatibility with the older desktop software and print tooling that is the usual reason for converting in the first place. Use PNG when something else has to open the file, WebP when only a browser will. And in every case keep the SVG. It is the master; the PNG is a render you can reproduce at any size in a couple of seconds.

Nothing is uploaded — and the SVG is cleaned before it is drawn

Most SVG-to-PNG sites work by posting your file to a server, rendering it there and sending back a link. That means your artwork sits on someone else's machine, under someone else's retention policy, often with a queue and a size limit attached. For an unreleased brand mark, a client's identity work under NDA, or a system diagram, that is a real disclosure, not a theoretical one.

Here the file is read locally, rendered by your own browser's SVG engine, and returned as a blob. No request is made, which you can verify in the network tab, or more simply by turning off your connection and converting anyway. There is no size limit beyond what your own machine can hold, and batch conversion costs nothing because there is no queue.

Because the rendering is local, sanitisation matters more here than it would on a server, not less. An SVG is XML that can carry <script> blocks and inline event handlers like onload, and a malicious file would be executing in your browser session. Before anything is drawn, script tags, inline event handlers and javascript: URLs are stripped from the markup, and the tool reports what it removed. External references are reported too: images, stylesheets and fonts pulled from a remote URL are never fetched during rasterisation, so instead of letting you download a PNG with a blank space where the photo should be, the tool tells you which references were dropped.