SVG to PNG Converter

Convert SVG to PNG at the exact pixel size you need

Drop one or more .svg files onto the upload area, choose an output size, and click Convert All. The SVG is parsed, rendered by your browser, drawn onto a canvas at the dimensions you asked for, and encoded as PNG. Everything runs locally in the page — the file is read with the browser's own file API and never sent to a server, so nothing you convert leaves your machine. Files up to 50 MB are accepted, and you can queue a batch.

The reason this conversion needs any settings at all is that an SVG does not have a size in the way a photograph does. It is a set of drawing instructions — move here, draw a curve of this radius, fill it with this colour — expressed in an abstract coordinate space. Nothing in the file commits to a number of pixels. A PNG, by contrast, is nothing but a fixed grid of pixels. So converting SVG to PNG means picking a resolution, and that single decision determines whether the result looks razor sharp or soft and disappointing. Everything below is about picking it well.

How the output dimensions are decided

The tool works out a base width and height for each file, then applies your settings on top. The base comes from the SVG itself, in this order:

• The width and height attributes on the root <svg> element, if both are present and numeric. An element declared as <svg width="240" height="120"> gives a base of 240×120.
• The third and fourth numbers of the viewBox, if width and height are missing. viewBox="0 0 512 512" gives a base of 512×512. This is the usual case for icon sets, which deliberately ship without fixed dimensions so they can be sized by CSS.
• A fallback of 800×600, if there is neither. This is a last resort, not a guess at your artwork — if you get an 800×600 output with your drawing floating oddly inside it, the source SVG had no size information and you should add a viewBox to it.

One thing to watch: the width and height attributes are read as plain numbers, so units and percentages are truncated rather than interpreted. An SVG declared width="100%" yields a base width of 100, and width="10em" yields 10. Those files will convert to tiny images. The fix is to set a custom width explicitly, or to edit the root element to carry a real pixel size or a viewBox.

Scale and custom width multiply — they do not override each other

There are two controls. Scale (1x, 2x, 3x, 4x) multiplies the base dimensions. Custom width replaces the base width with the number you type and recomputes the height from the original aspect ratio, so the artwork is never stretched.

If you set both, they combine: the custom width is applied first and the scale multiplier is applied to it afterwards. A custom width of 1024 with the scale left at its 2x default produces a 2048-pixel-wide PNG, not a 1024-pixel one. To get an exact pixel width, set the custom width and change the scale to 1x. This is worth remembering because 2x is the default, and it is the most common source of surprise output sizes.

Height always follows from the width and the source aspect ratio. There is no separate height field, no crop, and no padding control; if you need a square canvas around a non-square drawing, add the padding in the SVG before converting.

Why 2x and 3x exist: rendering for high-density displays

A CSS pixel is a unit of layout, not a physical dot. On a standard display one CSS pixel is one hardware pixel. On the high-density panels used by most current laptops and phones, one CSS pixel is drawn with two, three, or occasionally more hardware dots along each axis. An image displayed 200 CSS pixels wide on such a screen is being asked to fill 400 or 600 real dots.

If you export the PNG at exactly its display width, the browser has to invent the missing dots by interpolation, and the result looks soft — noticeably so on the thin strokes, small text and crisp corners that vector artwork is usually chosen for in the first place. Exporting at 2x or 3x and then displaying the image at the smaller CSS size means the extra detail is already there.

Going bigger is not free. Pixel count grows with the square of the scale factor, so 4x is sixteen times the pixels of 1x, and PNG is lossless — there is no quality dial to claw the bytes back. For flat vector artwork PNG compresses well, but a 4x export of a detailed illustration can be a very large file. Export at the largest size you will actually display, not the largest the dropdown offers.

The obvious question: if scaling is the whole problem, why rasterise at all? Because plenty of destinations will not take an SVG — email clients, some CMS uploaders, app store listings, chat apps, Office documents, print workflows, OG and social preview images. Where SVG is accepted, keep it. It stays sharp at every size and is usually smaller.

Fonts: the failure mode that catches everyone

Text in an SVG is normally stored as actual text with a font-family instruction, exactly like text in a web page. The file says "render the word Acme in Helvetica Neue, semibold, 32 units". It does not contain the letterforms.

Rendering therefore depends on whether the machine doing the rendering can resolve that font. Yours may have it installed and produce a perfect result; a colleague's machine may not, and the browser substitutes something else. Metrics differ between typefaces, so a substituted font does not merely look different — it changes the width of the text, which can push it out of a box, overlap another element, or wrap where nothing wrapped before. Because the rendering is what gets frozen into the PNG, the damage is permanent in the output.

There is a second constraint. When an SVG is rendered as an image rather than inlined into the page, browsers treat it as an isolated document with no network access: it cannot fetch external resources. That means:

• A @font-face rule pointing at a font file on a server — a Google Fonts URL, a self-hosted .woff2 — will not load. The text falls back.
• An <image> element referencing an external bitmap by URL will not load, and that part of the drawing comes out empty.
• An external stylesheet linked from the SVG will not load, so any styling that lived there is lost.
• Scripts inside the SVG do not execute, and SMIL animation is captured at its initial state rather than animated.

Anything referenced by a data: URI embedded in the file — a base64 font in a @font-face rule, a base64 raster image — is self-contained and does render. So do inline <style> blocks, gradients, filters, masks and clip paths, which are all internal to the document.

Making text reliable

Ranked from most to least robust:

• Convert text to outlines before exporting the SVG. In Illustrator this is Type → Create Outlines; in Inkscape, Path → Object to Path; in Figma, Outline Stroke / flatten. The letters become vector shapes, and font availability stops mattering entirely. This is the right answer for logos and any artwork you hand to other people. The trade-off is that the text is no longer editable or selectable.
• Embed the font as a base64 data: URI inside an inline @font-face. Keeps the text editable and renders correctly, at the cost of a much bigger SVG — and check that the font's licence permits embedding.
• Use a font you are certain is installed locally and name a sensible fallback stack. Fine for a quick personal export, unreliable for anything shared.

Quick diagnostic: open the SVG directly in your browser as a file before converting. What you see there is very close to what the converter will capture. If the fonts are wrong or a picture is missing in that preview, fix the SVG — the PNG will have the same problem.

Transparency, colour and what PNG preserves

The canvas is not filled with a background colour before the artwork is drawn, so any area the SVG leaves uncovered stays transparent in the PNG. An icon with no background rectangle exports with a genuinely transparent background and will sit correctly on a dark page. If you want a solid backdrop, draw a full-size <rect> as the first element in the SVG.

PNG encoding is lossless: there is no quality setting here, and no compression artefacts. The pixels the browser rendered are the pixels you get, complete with the anti-aliased edges that make curves and diagonals look smooth. Those soft edge pixels are also why a PNG cannot be scaled up afterwards without going soft — if you later need a bigger version, come back to the SVG and re-export, rather than enlarging the PNG.

Batches, output files and common problems

Files convert one after another, each with its own status and its original and output size. All files in a batch share the same scale and custom width, so mixed icon sizes are best done as separate runs. Output keeps the source name with .svg replaced by .png. "Download All" saves each file individually rather than as a ZIP, and browsers may ask permission the first time a page saves several files at once.

• "Failed to load SVG". Almost always malformed XML — an unclosed tag, a stray ampersand that should be &, or a file that is not really SVG. SVG parsing is strict; open the file in a browser to see the parse error.
• The output is 800×600 with the drawing in a corner. The source has no width, height or viewBox. Add a viewBox.
• The output is much bigger than expected. Custom width is being multiplied by the scale setting. Set scale to 1x.
• Part of the image is missing. That part was an externally referenced image or was styled by an external stylesheet. Embed it.
• The drawing is cropped. Content drawn outside the viewBox is clipped, because the viewBox defines the visible region. Widen it in the source.
• Nothing appears after dropping a file. Non-SVG files and files over 50 MB are ignored.