Convert SVG to PNG
Rasterize a vector at any pixel size, with transparency kept — no upload.
The SVG is rasterized by your browser in this tab — nothing is uploadedRasterize a vector SVG to a PNG at the exact pixel size you choose
or drag & drop it here
SVG
Natural size detected in the SVG.
Preview
Choose or paste an SVG and the rasterised result shows up here, with its real dimensions and file size.
How it works
Everything runs in your browser — the SVG is never uploaded and there is no sign-up.
Fonts and any images the SVG pulls in by URL (e.g. <image href="https://…">) will not appear — the browser blocks them on this page for security. Convert text to paths in your vector editor before exporting if you need to keep the typography.
The result is a brand-new image with no metadata.
About converting SVG to PNG
Drop in an SVG and choose exactly how big the PNG should be — a width in pixels, or a scale like 2x or 4x — and the page draws the vector onto a canvas at that size and hands you back a .png. It happens in this tab, in your browser, so there is no upload, no queue and no file limit; a hundred icons is as instant as one. The reason people come here is rarely that they dislike SVG. It is that something in front of them will not take it: an email client, an older CMS, a marketplace listing, a chat window, a slide, a thumbnail field. PNG is the format everything opens, so a vector has to become pixels before it can go there.
That word — pixels — is the whole thing to get right, and it is where naive converters quietly fail. An SVG has no fixed resolution: it is a set of drawing instructions that stay sharp at any size, which is exactly why designers work in it. A PNG is the opposite: a fixed grid of pixels, sharp only at the one size it was rendered at, and blurry the moment something scales it up. So the single decision that matters is the size you rasterize at, and you have to make it now, on purpose. Render an icon at 32 pixels and blow it up to 512 later and it turns to mush; render it at 512 and it is crisp everywhere smaller. This is why the tool leads with a size control instead of a single button — pick the largest size you might plausibly need and scale down from there, never up.
Transparency is the other thing this page is careful about, because it is the second most common reason for the search — people literally look for a PNG “with no background”. A canvas is transparent by default and PNG carries a full alpha channel, so an SVG with a transparent background comes out as a PNG with a transparent background, no white box bolted on behind it. That is the opposite of what a JPG would do, and it is the point of choosing PNG here rather than JPG for a logo or an icon.
Two honest limits belong up front, both about text. When a browser rasterizes an SVG it loads it as an image, and an SVG used as an image runs in a locked-down mode: scripts are disabled and external resources are not fetched. That is good for you and it is also the source of the classic surprise — a web font referenced by URL will not load, and a font that only exists on the designer’s machine will not be there either, so text can silently fall back to a different typeface. The fix is to convert text to outlines (paths) in your editor before exporting the SVG; then the letters are shapes and no font is needed. The related trap: an SVG that uses a foreignObject element taints the canvas and cannot be exported at all, so the page detects that and tells you rather than handing back a blank file.
Everything else is deliberately quiet. A fresh PNG carries no EXIF or GPS the way a camera photo does, so there is nothing here to strip — and nothing is sent anywhere, which matters when the SVG is an unreleased logo or a client asset. The only ceiling is your device: canvases have a maximum size, so an extreme scale on an already-large drawing can fail, and the page shows a clear error rather than a broken image.
Why a PNG has a size and an SVG doesn’t — and how to pick it
The one idea worth internalising before you convert anything: an SVG is resolution-independent and a PNG is not. An SVG is markup — paths, shapes and coordinates the browser draws fresh at whatever size it is displayed, so it is sharp on a watch face and on a billboard. A PNG is a raster: a fixed grid of pixels, defined by MDN as a lossless format that stores the image as that grid. Rendering the vector into the grid is a one-way step called rasterization, and the grid you choose is permanent. Scale that grid up afterwards and the browser has to invent pixels it never drew, which is what “blurry” means. So the size is not a detail to accept as a default; it is the whole decision.
There is a specific trap that makes naive converters produce fuzzy output. If an SVG declares a viewBox but no explicit width and height, it has no intrinsic pixel size, and the CSS specification says a replaced element in that situation falls back to a default object size — historically 300 by 150 pixels. Draw that onto a canvas without setting dimensions and you get a small, soft image no matter how detailed the vector was. The correct approach, and the one this page takes, is to read the viewBox to learn the drawing’s aspect ratio and then render at a size you specify — so a square icon exported at 512 is a genuine 512-by-512 raster, not a 150-pixel one stretched up.
| What you’re making | A sensible pixel size | Note |
|---|---|---|
| A favicon or app icon | Export at 512 and scale down | Icons are shown at many sizes; render the largest once and downscale. The favicon generator on this site turns one square image into a full icon set. |
| A logo for email or a slide | 2x its display size | If it appears at 300px wide, export at 600px so it stays crisp on high-density (Retina) screens. |
| A thumbnail or list image | The exact display width | No benefit to going bigger than it is shown; match the slot to keep the file small. |
| Something for print | Display size in inches x 300 | Print wants roughly 300 pixels per inch, so a 2-inch logo is about 600px. Note that PNG output here is sRGB, not CMYK. |
The upper bound is the canvas itself. Browsers cap how large a canvas can be — in current Chromium a single side up to 16,384 pixels works while 32,767 fails, and there is also a total-area limit, so a very large drawing at a very high scale can exceed it. When that happens the honest outcome is an error, not a silently blank or truncated image, which is what this page surfaces. In practice you will not hit it for icons and logos; it only matters if you try to rasterize a full-bleed illustration at 8x.
The two things that quietly break SVG rasterization: fonts and external references
When any browser rasterizes an SVG, it does so by loading the file as an image, and that changes the rules. As MDN documents for using SVG as an image, an SVG loaded this way runs with JavaScript disabled and, critically, external resources such as images and stylesheets are not loaded — they can only be used if inlined as data URIs. This is a security boundary, and it is deliberate. It is also the single biggest source of “it looked fine in the editor but the PNG is wrong” surprises, and almost always the culprit is text.
Fonts are external resources. If your SVG sets text in a web font pulled from a URL, that font will not be fetched during rasterization, and the browser substitutes whatever it has — different letterforms, different width, sometimes different line breaks. The same happens with a font that is installed only on the designer’s computer: it is simply not there when the file is rendered elsewhere. The durable fix is to stop depending on fonts at all: in Illustrator, Inkscape, Figma or your editor of choice, convert text to outlines (also called “create outlines” or “object to path”) before exporting the SVG. That replaces each glyph with a vector shape, so the letters render identically everywhere because no font lookup is involved. The trade-off is that outlined text is no longer editable as text — so keep an editable master and outline a copy for export.
The second breakage is structural. An SVG can embed an HTML subtree inside a foreignObject element, and content brought in that way taints the canvas: the browser marks the canvas as not origin-clean and refuses to export it, throwing “Tainted canvases may not be exported”. There is no rasterized PNG to be had from such a file through a browser canvas, so rather than fail with a cryptic message the page detects a foreignObject and tells you plainly. If you control the SVG, the fix is to replace the foreignObject content with native SVG elements (real text and shapes) so the whole drawing is genuine SVG and rasterizes cleanly. The same principle covers any linked bitmap or stylesheet inside the file: inline it as a data URI, or the render will quietly drop it.
Reference tables
FAQ
Why does my PNG come out blurry or low-resolution?
Because an SVG has no built-in pixel size, so the size you export at is the only thing that decides sharpness. If a converter renders at a small default and you scale the result up, it blurs — a PNG is a fixed grid of pixels and cannot gain detail it was never rendered with. The fix is to set the size before converting: choose a width in pixels or a scale factor (2x, 4x) and render at the largest size you might realistically need, then shrink from there. Rendering big and scaling down stays crisp; rendering small and scaling up never does. This is exactly why the page puts a size control first instead of a one-click button.
Can I get a PNG with a transparent background, with no white box?
Yes. The canvas the SVG is drawn onto starts fully transparent, and PNG supports a real alpha channel, so an SVG whose background is transparent produces a PNG whose background is transparent — no white rectangle added behind it. That is the main reason to convert to PNG rather than JPG for logos, icons and stickers, since JPG has no transparency and would fill the empty area with a solid colour. If your source SVG has a coloured or white background rectangle drawn into it, that shape will be rasterized too, so remove it in your editor first if you want the PNG to be see-through.
The text or fonts in my SVG look wrong after converting — why?
Because a browser rasterizes an SVG by loading it as an image, and an SVG used as an image runs in a locked-down mode where external resources are not loaded. A web font pulled in by URL will not be fetched, and a font that only exists on the machine that made the SVG will not be present either, so the text falls back to a different typeface — sometimes with different spacing or line breaks. The reliable fix is to convert your text to outlines (paths) in your vector editor before exporting: the letters become shapes and no font is needed to draw them. This is a property of how SVGs render as images, not a limitation of this tool specifically.