SVG to PNG Converter

What actually happens when SVG becomes PNG

SVG is a set of drawing instructions — "a circle of radius 30 at (62,60)" — while PNG is a fixed grid of pixels. Converting between them is rasterization: your browser executes the instructions at a chosen pixel size and freezes the result. This tool does it with the browser's own renderer: the markup becomes a Blob, loads into an Image, is drawn onto a <canvas>, and canvas.toBlob('image/png') encodes the download — four steps, zero uploads. Because the source is vector, exporting at 4× is just as sharp as 1×; there is no upscaling blur, ever.

How the pixel size is decided (the part everyone gets wrong)

An SVG doesn't necessarily know how big it is. This tool resolves its natural size in the same priority order a browser uses, and tells you which rule applied:

• 1. width/height attributes — physical units convert at the CSS reference of 96dpi: 1in = 96px, 1cm ≈ 37.795px, 1mm ≈ 3.7795px, 1pt = 96/72 ≈ 1.333px. So width="10cm" is a 378px-wide PNG at 1× — not 10cm of "print resolution"; PNG has no physical size, only pixels.
• 2. The viewBox — when the attributes are missing (or unresolvable, like width="100%"), the viewBox's width/height in user units become pixels one-for-one. viewBox="0 0 240 120" → a 240×120 natural size.
• 3. The spec default, 300×150 — an SVG with neither is defined by the SVG spec to be 300×150 CSS px. The tool uses it and says so on the page, because a silent 300×150 export from a logo that "should" be 2000px wide is exactly the kind of surprise this tool exists to avoid.

A worked example: a file with width="10cm" height="5cm" resolves to 378×189px. Choose 2× and you get 756×378; type 1200 into the exact-width field and you get 1200×600, height derived from the aspect ratio.

Converting a folder of icons in one pass

An icon set is the normal reason anyone opens an SVG converter, so the file picker and the drop zone both take as many files as you hand them. Select or drop as many .svg files as you like and the queue converts them one after another at the size and background you picked, giving each its own row with its output pixel size, byte size and Download button — plus a Download all (.zip) button that packs the whole set into a single archive. A file that will not parse gets its own error row naming that file, and the rest of the batch still finishes. Two practical details worth knowing:

• The size setting applies to every file, and it is relative. "2×" means twice each SVG's own natural size, so a 24px icon becomes 48px and a 512px one becomes 1024px — mixed-size sources stay proportionally different. When you need every output identical, type a number into the exact-width field instead: that pins the width of all of them and derives each height from its own aspect ratio.
• Names carry through, extensions swap. icon-home.svg becomes icon-home.png, inside the .zip as well as on the individual download, so a batch drops straight into an existing folder structure. Two sources with the same name get -2, -3 appended rather than silently overwriting each other in the archive.

The .zip itself is written here in the page — a few dozen lines that emit a standard archive with the STORE method and a CRC-32 per entry. PNG is already a DEFLATE-compressed format internally, so deflating it a second time typically buys a percent or two at most while costing real time on a large batch; storing is the honest choice, and every unzip tool reads a STORE entry.

The honest part: external references render blank

When a browser rasterizes SVG through an image element it runs in a sandbox that does not fetch external resources — no remote <image href="https://…">, no <use> pointing at another file, no @import, no web font from @font-face url(…). Most converters quietly hand you a PNG with holes where those were. This tool scans the markup for exactly those patterns first and lists every finding above the preview, so you know before downloading. The fixes: embed raster images as data: URIs (the Image to Base64 tool does this), and convert text to paths in your editor if it uses a web font.

Honest limits

• Memory is the real batch limit, not a file count. Nothing caps the queue, and files are rasterized one after another rather than in parallel, so only one canvas exists at a time — but every finished PNG is then kept in memory until you clear the batch (that is what makes each row's Download and the .zip instant), and packing the archive briefly holds a second copy of the set. Forty 64px icons at 2× costs a few hundred KB and you will never notice. Forty 1024px illustrations at 4× means forty 4096×4096 PNGs, which is where a tab starts to struggle — if it does, drop the scale or convert a few at a time.
• <foreignObject> is unreliable. HTML embedded in the SVG rasterizes inconsistently across browsers when loaded as an image — the tool flags it when present, but can't guarantee that region renders.
• Animations freeze. SMIL and CSS animations export as their first frame; scripts inside the SVG never run at all (a security feature of image loading, not a bug).
• Fonts must be local. Text keeps its font only if that font is installed on your machine; otherwise the browser substitutes. Text-as-paths is the portable answer.
• Output is capped near 16384px a side — the browser's canvas limit. The tool caps the scale and tells you when it did.
• PNG→SVG is not offered. That's raster tracing — approximation, not conversion — and pretending otherwise would be dishonest.