Take one icon, drop it into three different SVG converters, and you can get a 300 × 150 PNG, a 24 × 24 PNG and a 1024 × 1024 PNG. None of the three is a bug. The file simply never said how big it was, and each tool answered the question differently.
An SVG Has No Pixels Until Something Draws It
A raster image carries its dimensions in its header. A PNG is 512 by 512 the moment it exists, before anything renders it, and every tool that opens it agrees.
An SVG carries geometry. A path is a list of coordinates in user units, and a user unit becomes a pixel only when a renderer decides on a scale. Nothing in the file is obliged to fix that scale: width and height on the root element are optional, and the SVG 2 specification gives them an initial value of auto, which behaves as 100%.
So <svg viewBox="0 0 24 24"> is a complete, valid document that specifies no size at all. It is also what almost every icon set ships, because an icon that sizes itself to its container is exactly what a web developer wants. It is the rasterizer that has a problem, not the file.
What Each Attribute Actually Decides
A rasterizer works down this list. The first row that applies is the answer.
| What the file says | Resulting size | How common |
|---|---|---|
| width and height in absolute units | Exactly that, in px | Illustrator and Inkscape exports |
| width and height in %, with a viewBox | The viewBox width and height | Icon sets, Figma, most SVG on the web |
| No width or height, with a viewBox | The viewBox width and height | Markup copied out of a component |
| width and height only, no viewBox | Exactly that, but it will not scale | Hand-written and older files |
| Neither one | 300 × 150, the CSS default | Rare, and always a mistake |
Millimetres, Points and the 96-Pixel Inch
width does not have to be a plain number. Inkscape writes 210mm for an A4 drawing, print-oriented files use pt or in, and all of them are legal.
CSS fixes the conversion: one inch is 96 pixels, so a point is 96/72 pixels, a millimetre is 96/25.4, and a centimetre is 96/2.54. That is a definition rather than a measurement — the CSS pixel is an anchored unit, not the physical dot on your screen — which is why a 210mm SVG rasterizes to 794 pixels wide and not to whatever your monitor's real density happens to be.
A number with no unit is already in pixels, since a user unit and a px are the same thing at the root. Percentages and font-relative units such as em are the odd ones out: they resolve against a containing block the file does not carry, so a converter cannot treat them as a size at all. It has to fall through to the viewBox, which is exactly what width="100%" was always meant to do.
No viewBox means the drawing cannot be scaled
This is the failure people describe as "my icon exported tiny in the corner". Without a viewBox there is no mapping from user units to the canvas, so enlarging the root gives the drawing more room instead of making it bigger. Setting width to 4x produces the original artwork sitting at the top left of a large empty PNG. Adding viewBox="0 0 W H", using the file's own declared width and height, turns the size into a real scale factor.
Convert an SVG to PNG at the size you actually want
Measured before it is drawn, exported at 2x or an exact pixel size, on a transparent or solid background.
What Does Not Survive Rasterization
An SVG used as an image is rendered in what SVG 2 calls secure static mode. It is a deliberate restriction, not a limitation of any one tool: an image is allowed to draw, and nothing else. Four things stop working, and all four are silent.
Web fonts
The document cannot fetch anything, so a font loaded over the network is never available and live text falls back to whatever the device already has. Convert text to outlines before exporting and the glyphs become geometry that renders identically everywhere.
Linked bitmaps and stylesheets
An <image> element pointing at a URL, an external stylesheet, an @import rule: all blocked, all leaving a hole in the output. Embedding the bitmap as a data URL inside the markup is what makes it come through.
Scripts
Never executed. Anything a script would have drawn or moved is simply absent, which is why script-generated charts export blank.
foreignObject
HTML embedded in an SVG renders in a browser and not inside an image. That includes the wrapped, styled text people reach for when SVG text handling gets awkward.
Rasterize at the Target Size, Not Before It
There is a right and a wrong order to do this in, and the difference is visible.
The wrong order renders the SVG once at its natural size, gets a small bitmap, then scales that bitmap up to the requested dimensions. A 24-pixel icon asked for at 512 becomes 24 pixels of image interpolated across 512, which is soft, and no amount of filtering recovers what was never drawn.
The right order writes the target size onto the SVG first and lets the renderer resolve the geometry at that resolution. Every curve is computed at 512 pixels, so the edges are as crisp as the vector allows. That is the entire point of keeping artwork in vector form, and it is the one place where a converter either does the job or quietly ruins it.
One thing this cannot fix: raster content embedded inside the SVG. A photograph pasted into a vector file is still a photograph, and enlarging the document enlarges it exactly as badly as enlarging it on its own would.
Which Pixel Size to Export
Screen assets follow device density. Fixed requirements do not, and are worth looking up rather than guessing.
| Destination | Export at | Why |
|---|---|---|
| Interface icon on a modern screen | 2x the display size | Roughly two device pixels per CSS pixel |
| High-density phone display | 3x the display size | Covers the densest current panels |
| Favicon source | 512 × 512 | One source to generate the smaller set from |
| Apple touch icon | 180 × 180 | The size iOS requests for a home screen |
| App store listing | 1024 × 1024 | What Apple and Google both ask for |
| Open Graph preview | 1200 × 630 | Raster only; SVG is not accepted |
When PNG Is the Right Answer
Keep the SVG wherever you can. It is smaller for line art, it scales without limit, and it can be restyled with CSS instead of re-exported.
Convert at the boundaries, where SVG was never accepted. App icons and store listings require raster files at fixed sizes. Most email clients strip SVG outright, so a logo in a newsletter has to be a PNG. Open Graph and social preview images are raster only. Older Office and slide software, and a number of PDF and print pipelines, either ignore SVG or render it inconsistently enough that you would rather control the result yourself.
PNG rather than JPEG for all of it, because these are flat-colour drawings with hard edges — precisely the content JPEG's frequency-based compression handles worst, ringing around every edge — and because PNG carries the alpha channel that keeps an icon transparent against whatever it sits on.
Frequently Asked Questions
Related Tools
Keep Reading
What the JPEG Quality Slider Is Really Doing to Your Photo
Quality 80 scales the quantization tables to 40 percent, it does not keep 80 percent of the picture. Where the setting stops being free, and why PNG has no dial.
Why Resized Images Come Out Noisy, and the Fix Nobody Applies
Bilinear sampling reads four pixels no matter how far you shrink, so a 20:1 reduction ignores 396 of every 400. Halving in steps reads all of them.
Base64 Images: The 33% Overhead Explained, and When It's Worth It
A base64 image is a third larger than the file, never cached on its own, and often silently dropped by the email client you were embedding it for.
Rounded Image Corners: When to Use CSS and When to Bake Them In
border-radius is ignored by Outlook and dropped by most PDF exporters. Where a permanent round is the only option, and why the file must be PNG.