Every SVG-to-PNG "converter" is really one thing: a rendering engine sampling your vector artwork onto a pixel grid. The converter's quality is the engine's quality — and the best engine on your machine is the browser you're reading this in. Here's how rasterization actually works, the size math worth knowing, and the traps that produce blurry or mis-rendered exports.
An SVG file contains drawing instructions — paths, fills, gradients, text elements. A PNG contains a fixed grid of pixels. Conversion means executing those instructions at a chosen grid size and recording the resulting pixels. Two consequences follow. First, the output can be any size you want, because the instructions are resolution-free. Second, the render is only as faithful as the engine executing it: browsers implement the SVG spec more completely and more consistently than most desktop converters, which is why an SVG with CSS classes or filters can look wrong in one tool and perfect in another.
The SVG to PNG Converter on this site leans into that: it parses your file with the browser's own parser, infers its native size exactly the way a browser does, and rasterizes with the browser's renderer at whatever scale factor you pick, from 0.5x to 10x.
Use a scale factor when the SVG has a meaningful native size (most do). Exporting at 3x means "render this three times bigger than its declared size" — a 300×200 diagram becomes 900×600, which is 540,000 pixels, nine times the 1x pixel count. Pixel count grows with the square of the scale, so budget accordingly:
| Scale | 512×512 source exports as | Pixels | Raw RGBA memory |
|---|---|---|---|
| 1x | 512×512 | 262,144 | 1 MiB |
| 2x | 1024×1024 | 1,048,576 | 4 MiB |
| 4x | 2048×2048 | 4,194,304 | 16 MiB |
| 8x | 4096×4096 | 16,777,216 | 64 MiB |
Raw memory is width × height × 4 bytes; the compressed PNG on disk will be much smaller. Use fixed pixel dimensions when a platform demands an exact size — favicon sets, app store masters, social preview images.
SVG width and height accept CSS absolute units, and browsers resolve them at 96 pixels per inch. The conversions worth memorizing: 1in = 96px, 1pt = 96/72 ≈ 1.3333px, 1pc = 16px, 1cm ≈ 37.795px, 1mm ≈ 3.7795px. So a business card SVG declared as width="3.5in" height="2in" rasterizes at 336×192 at 1x. For print at 300dpi, you're asking for 300/96 = 3.125x — export at that scale (or a round 4x) and you'll have press-ready pixels.
/favicon.ico with 16×16 + 32×32, plus a 32×32 or 180×180 PNG declared in <link> tags.One master SVG exported at each of those sizes covers the whole matrix. If you're doing this often, our Favicon Generator packages the full set from one image.
Three usual suspects. No width/height and no viewBox: the renderer has nothing to compute proportions from — browsers fall back to 300×150 or a tool-specific default; fix the file. Upscaling an earlier PNG instead of re-rendering the SVG: stretching existing pixels can never add detail; always rasterize from the SVG at the final size. Filters and half-pixel strokes: very thin strokes on non-integer coordinates anti-alias into soft gray; exporting bigger helps, but snapping strokes to whole pixels fixes it. And remember text: unless fonts are embedded or converted to outlines, output depends on the fonts installed on the rendering machine.
PNG makes sense for icons-in-transition, email, Office apps, app-store assets, and anywhere SVG isn't supported. But if the image lives on a website you control, shipping the SVG itself is usually better: it stays sharp on every screen density, typically weighs less for simple art, and can be recolored with CSS. The reverse direction has its own use cases — tracing a raster logo back to SVG when the vector source is lost. Rasterize when a platform forces you to; otherwise keep vectors.
Drop files, pick 1x–10x, download sharp PNGs. Runs entirely in your browser.
Convert SVG to PNG →Rasterization is sampling, and quality = engine × target size. Use the browser engine, export at the size the destination actually needs (2x for retina, exact pixels for stores), keep transparency unless the destination composites over white, and hold on to the SVG as your master. The math is all multiplication — 512 at 4x is 2048, and pixels scale with the square.
Export at 2x the display size for standard retina screens, or at the exact size a platform requires. Pixel count scales with the square of the scale factor: a 512×512 icon at 4x is 2048×2048 = 4,194,304 pixels; at 8x it is 4096×4096 = 16,777,216 pixels and needs 64 MiB of raw RGBA memory. Beyond what the target actually displays, extra pixels just make heavier files.
Browsers rasterize SVG against the CSS reference resolution of 96 pixels per inch, so 2in × 96 = 192px. The full conversion per the W3C spec: 1pt = 96/72 = 1.3333px, 1pc = 16px, 1cm = 37.795px, 1mm = 3.7795px. A 300dpi print export is the same artwork scaled by 300/96 ≈ 3.125x.
Not at the moment of conversion: the vector curves are re-rendered at the target size, so a 4x PNG is genuinely sharper than a 1x one. What you lose is scalability — the PNG is frozen at that pixel grid, and enlarging it later looks soft. Keep the SVG as the master and re-export when you need a bigger size.
SVG text renders with locally installed fonts unless the file embeds them. If the font named in the file isn't on the machine doing the rasterizing, the browser substitutes another and spacing shifts. Server-side converters have the same issue with their font library. Convert text to outlines in a vector editor for identical output everywhere.