An SVG describes shapes: this path, this fill, this stroke width. It has no resolution, because it has no pixels. Render it at 40 pixels or 4,000 and it is equally sharp — the renderer solves the shapes at whatever size you ask for.
A PNG is a grid of pixels. Rasterising is the act of asking “what does this look like at exactly this size” and freezing the answer.
That is a one-way door, and choosing the size is the whole of the decision.
Why “what size is this SVG?” has no good answer
SVGs carry two different notions of size and people conflate them constantly.
viewBox defines the coordinate system — the space the shapes are drawn in. A viewBox="0 0 24 24" means the artwork occupies a 24-by-24 grid. This is not a pixel size; it is a ruler.
width and height attributes, when present, suggest a default rendering size. They are a hint, and they are frequently absent, frequently wrong, and frequently inherited from whatever the designer’s canvas happened to be.
So an icon whose width says 64 is not a 64-pixel icon. It is a shape description with a suggestion attached. Rendering it at 512 loses nothing.
This is why our SVG to PNG tool lets you set width, height or a scale factor rather than offering a single “convert” button. In testing, a 240×120 viewBox was rendered to 800×400 and a file declaring 64×64 was rendered to 800×800 — both perfectly sharp, because the source had no resolution to exceed.
Choosing the output size
The rule: rasterise at the exact pixel size it will be displayed, multiplied by the pixel density you need to support.
For screens, that means roughly doubling. A logo displayed at 200 pixels wide should be rasterised at 400 for a high-density display. Going beyond that wastes bytes for no visible gain.
For print, work from physical size and resolution: 300 DPI at 2 inches wide is 600 pixels. Print at 150 and it will look soft; there is no recovering the detail afterwards.
Do not rasterise small and scale up. This is the mistake that undoes the whole point of starting from a vector. Every pixel of enlargement is invented by an interpolation algorithm, and edges that were mathematically sharp become soft. If you need it at four sizes, rasterise four times from the SVG.
What actually changes
Text becomes shapes. An SVG referencing a font renders with whatever the renderer can resolve; once rasterised, the letterforms are pixels. No longer selectable, searchable or restylable — and if the font was unavailable at render time, the substitution is now permanent. Convert text to outlines in the SVG before rasterising if the appearance matters.
Transparency survives, if the format allows it. PNG has a real alpha channel and it works: in testing, a rounded corner rasterised from a transparent SVG came back with alpha 0, so the transparency was genuinely preserved rather than flattened to white. Rasterise to JPG instead and transparency is gone, because JPG has no alpha channel at all — transparent areas become white or black depending on the encoder.
Interactivity and animation disappear. SMIL animation, CSS inside the SVG, hover states, embedded links — all of it evaporates. A PNG is a picture.
Filters may render differently. Blurs, drop shadows and other SVG filter effects are resolved by the renderer, and different renderers produce slightly different results. If the effect is important, check the output rather than assuming.
External references break. An SVG pointing at an external font, image or stylesheet may render incompletely if the renderer cannot fetch it. Self-contained SVGs rasterise predictably; ones with dependencies do not.
When not to rasterise at all
For the web, usually don’t. SVG is a first-class image format in every current browser. It stays sharp at any density, is typically far smaller for logos and icons, can be styled with CSS, and needs no size decision at all.
Rasterise when something downstream requires a bitmap:
- Platforms that will not accept SVG uploads — most social networks, many marketplaces, some email clients
- Favicons and app icons, where a specific file set is required
- Documents and presentations whose format handles bitmaps more reliably
- Print workflows that specify raster output
- Anywhere the renderer is unknown and you need to guarantee appearance
That last one is the underrated reason. Rasterising removes the renderer’s judgement from the equation. If a logo must look exactly right in an environment you do not control, a PNG is a guarantee and an SVG is a hope.
Background: transparent or solid
The choice looks trivial and has consequences downstream.
Transparent is the flexible option and the right default for logos and icons that will sit on backgrounds you do not control. PNG’s alpha channel handles it properly, and anti-aliased edges blend correctly against whatever they land on.
Solid is required more often than people expect. Anywhere transparency is unsupported or badly handled — JPG output, some document formats, iOS home screen icons, certain email clients — a transparent PNG produces black, white or an artefact depending on what does the compositing.
The failure mode worth knowing: a dark logo exported transparent, then placed on a dark background by someone else, disappears entirely. It is not a rendering bug and nothing looks broken in your files; the artwork is simply invisible. If you are handing artwork to somebody, supply both variants and let them choose.
A note on batches
Rasterising one icon at one size is trivial. Rasterising forty at four sizes each is the point at which people start scaling PNGs instead, because doing it properly is tedious.
That is what the batch and ZIP export exist for — every size rendered from the source rather than from another PNG. It is the same argument as keeping photographic originals: derive from the source every time, and never from a derivative.
Working out the pixel size for print
Screen work is straightforward: display size times pixel density. Print needs one more step, and it is where most people guess.
The formula is:
pixels = physical size in inches × DPISo a logo printed 2 inches wide at 300 DPI needs 600 pixels. The same logo across a 4-inch card needs 1,200.
Useful reference points: 300 DPI is the standard for commercial print and is what most printers will ask for. 150 DPI is acceptable for large-format work viewed from a distance — a banner nobody stands closer than two metres from does not need 300. Below 150 you will see it.
Working in millimetres, divide by 25.4 first: an 85 mm business card is 3.35 inches, so a full-width graphic at 300 DPI needs about 1,004 pixels.
The advantage of starting from an SVG is that none of this is a compromise. You are not stretching an existing file to meet a requirement — you are asking the renderer for exactly the size you need, and it produces it at full sharpness. That is the entire reason to keep source artwork as vector.
Naming and organising a batch
Once you are rendering the same source at several sizes, the files multiply quickly and become indistinguishable. Two conventions save real time later.
Put the dimensions in the filename — logo-512.png, logo-192.png. Guessing an icon’s size from a thumbnail is a waste of a minute you will spend repeatedly.
Keep the SVG beside the exports. The single most common cause of blurry graphics is somebody months later finding only a PNG, needing it larger, and scaling it up because the source is gone. The vector is small; keep it in the same folder as the things derived from it.
Rasterise SVGs at any width, height or scale factor, with transparent or solid backgrounds and batch export, using SVG to PNG. Nothing is uploaded.