How the SVG to PNG/ICO Converter works
How it works
The converter reads your SVG markup as plain text and renders it through the same rasterization pipeline a browser uses. The markup is wrapped in a Blob typed as image/svg+xml and turned into an object URL, which is then loaded into an in-memory HTMLImageElement. That step lets the browser parse the SVG and apply its viewBox, gradients, and transforms exactly as it would in an <img> tag. The decoded image is drawn onto a 2D canvas with drawImage, and the canvas is encoded to PNG with toBlob('image/png'). Before rasterizing, the tool forces an explicit width and height on the <svg> root so each export lands at a predictable pixel size.
For ICO output, the same SVG is rasterized at 16, 32, and 48 pixels, and the three PNG frames are packed into a single ICONDIR container. That container is a compact binary format: a 6-byte header (a reserved word, a type field set to 1 for icons, and the frame count), followed by 16-byte directory entries recording each frame's dimensions, 32-bit depth, byte length, and offset, with the raw PNG bytes appended afterward.
The page also scans the markup for inline <script> tags, javascript: URLs, and on* event handlers before export. Preview remains available, but exported files only rasterize static geometry: no script in an SVG ever executes.
How the coordinate system works
The export size follows directly from the SVG 2 coordinate system. The viewBox attribute maps abstract user units onto the viewport defined by the root width and height. When viewBox and root size disagree on aspect ratio, the preserveAspectRatio rule applies, so geometry letterboxes instead of clipping.
Gradients, masks, and filters carry over because the browser itself rasterizes.
The standards also define boundary behavior. The SVG 2 specification and the HTML standard treat SVG loaded through an image as a secure static document, so scripts, event handlers, and external resources are not executed. An SVG that references an external image or font therefore renders with only its embedded content, which is why the preview can look sparse until resources are inlined. Keep graphics, fonts, and styles embedded so exports match the preview.
Use cases
Developers reach for this tool to generate favicon.ico and PWA manifest icons from a single logo SVG; to turn an inline vector into a raster for documentation, email signatures, or CMS uploads; and to produce crisp multi-resolution icons for desktop applications without installing a graphics suite.
Sizing is one click: pick any preset from 16 to 512 pixels and export.
Common mistakes
Most failed exports come from a few markup habits. Omitting the xmlns attribute on the root element can make the parser reject otherwise valid markup. Unclosed tags or stray ampersands break XML well-formedness before any geometry is drawn. A viewBox that disagrees with root width and height scales unexpectedly, because the browser stretches user coordinates to fill the viewport.
A full-size background rectangle paints over the transparency PNG and ICO would preserve, so check the root layer first.
Alternatives to rasterizing
Raster output is not always the right format. When an icon must scale across favicons, app tiles, and print, the SVG source stays the most flexible asset. PNG and ICO here serve legacy software, email clients, and image libraries that do not parse SVG.
Troubleshooting
A blank or failed preview usually means malformed markup, a missing xmlns attribute, or external images, fonts, or stylesheets the isolated rasterizer cannot fetch, so keep the SVG self-contained. If transparency appears lost, check that no background rectangle is drawn, since ICO frames keep a 32-bit alpha channel. Large SVGs with heavy paths can exhaust canvas memory, so reduce the export size or simplify paths. When the script-detection warning appears, exports contain only the static portion, so interactive or animated SVGs are flattened.