Rasterize SVG at the Right PNG Size

Two fundamentally different image types

SVG stores instructions — paths, curves, fills, text — and renders them at whatever size the viewer needs. PNG stores a fixed grid of pixels. Converting SVG to PNG freezes the instructions into pixels at one specific resolution, and that choice of resolution is the only decision that is hard to undo: a 200px raster can never become a sharp 2000px one.

This one-way nature is why the first rule of vector work is: keep the SVG. The PNG is a derivative for a specific destination; the SVG remains the editable source.

Choosing the export resolution

Work backward from the destination. For a PNG that will display at most 800px wide in a blog, export at 1600px wide (2× for retina screens) or 800px if bandwidth matters more than crispness. Common targets:

When in doubt, go bigger: downscaling a large raster is lossless for perception, upscaling is not.

How the tool rasterizes

The converter draws your SVG onto a browser canvas at the dimensions you specify, then encodes the canvas as PNG. Because it uses the same rendering engine that displays the SVG on the web, what you see in preview is what exports — with a few documented exceptions below. Transparency comes along free: SVG regions without fills export as transparent PNG, which is exactly why logos should export to PNG and never JPG.

The text and font trap

SVG text depends on fonts being available where the file renders. If the SVG references a font the rendering environment lacks, text may fall back to a system font or vanish. The robust fix is upstream: in your editor, convert text to outlines (paths) before export, which bakes the letterforms into geometry. If you do not control the source file, preview first — the converter's preview shows exactly how text will survive.

External resources and filters

Two more rendering edge cases worth knowing. SVGs that reference external images or stylesheets may export without them, because canvas rendering cannot fetch cross-origin resources. Complex SVG filters (feGaussianBlur and friends) usually render fine in modern engines but occasionally rasterize differently than a design tool's preview. Both problems are visible in the converter's preview before you commit.

Batch workflow for icon sets and assets

1. Confirm every SVG renders correctly in the preview (this catches font and external-resource issues).
2. Pick one export size for the whole set — uniform dimensions keep icon grids tidy.
3. Run the batch and download the ZIP.
4. Spot-check the most detailed icon at 100% zoom: hairline strokes below ~1px at the export size will look faint or vanish.

Hairline strokes are the classic vector-to-raster casualty. If 1px strokes disappear, either export at 2× or increase the stroke width in the source.

Backgrounds, padding, and safe margins

PNG exports preserve whatever bounds the SVG declares. If the output needs breathing room (app icons want it; social crops demand it), add padding in the SVG before converting rather than editing the PNG afterward — the image border tool can add a frame to the raster if the source is not editable. For app icons specifically, check whether the store applies its own corner rounding: keep critical content away from the extreme corners.

Troubleshooting rasterization failures

The blank-output case is the most common surprise: an SVG sized purely by CSS on a webpage carries no intrinsic dimensions, and the canvas needs a number. Setting export dimensions in the tool solves it directly.

PNG alternatives worth considering

Before exporting, ask whether the destination truly needs PNG. Transparent icons headed for the web often do better as WebP (smaller, same alpha) via the SVG-to-canvas pipeline or a two-step export. App stores and most forms specifically demand PNG or JPG, which removes the question. Print pipelines increasingly accept PDF-with-vectors, which keeps the artwork infinitely sharp — a better choice than any raster when the receiver supports it. PNG remains the answer when the destination demands pixels and supports nothing newer.

Export discipline for design systems

Teams that export SVG assets to PNG repeatedly benefit from a written convention: export dimensions keyed to usage tier (icon-small 32px, icon-medium 64px, icon-large 128px, marketing 2× target), one canonical export per tier, and the SVG master referenced in the component library documentation. The convention pays off the first time an asset needs re-exporting — which always happens, because design systems evolve. Keeping exports reproducible from the master SVG (rather than editing exported rasters) means updates are minutes instead of archaeology. The same discipline scales to full illustration libraries: masters in version control, exports generated on demand, no one ever opening a PNG in an editor to 'fix' it.

Exporting SVG at the size the destination needs

The core export decision is resolution, because SVG has none of its own — it is instructions, not pixels, and you choose the raster size at conversion time. The reliable rule: export at the largest size the asset will ever display, then let delivery formats shrink from there. An icon that appears at 48px on desktop but 96px on a 2x retina display needs at least 96px of raster; exporting at 48 and upscaling later gives soft edges on exactly the high-end screens you wanted to look sharp on.

Font and dependency handling is where SVG-to-PNG conversion surprises people. An SVG that references external fonts or linked images may render in a browser but convert to PNG with fallback fonts or missing pieces, because converters often render the SVG standalone, without the page context the fonts came from. Convert outlines-first where possible (text-to-paths in the design tool) for anything typographically sensitive, and embed rather than link referenced images.

Transparency and background deserve one deliberate choice per asset. SVG's default canvas is transparent; PNG keeps it, which is right for icons and logos that composite onto varying backgrounds, but wrong when the asset needs a solid background for a context that ignores alpha — email clients being the notorious one. Export two variants when in doubt: transparent for the web, background-filled for email and documents.

Common mistakes with this tool

• Exporting at display size instead of 2× and shipping blurry retina screens.
• Losing SVG text because the font never existed outside the design tool.
• Deleting the SVG after exporting, losing the only scalable master.
• Exporting icons at inconsistent dimensions and getting a ragged grid.

Frequently asked questions