How SVG to PNG Rasterization Works in Your Browser
An SVG file is XML, not pixels — a document tree of shapes, paths, gradients, and filters that some renderer must turn into a picture. This page delegates that job to the same engine that draws SVG on every website: the browser's own SVG renderer. The file is first read as text with a FileReader, wrapped in a Blob with the image/svg+xml MIME type, and turned into an object URL. Pointing an HTMLImageElement at that URL makes the browser parse the markup, build the DOM-style SVG tree, and paint it to an internal bitmap exactly as it would paint any inline SVG.
The key detail is what happens next. Raster images cannot be scaled up, so the canvas is sized from the SVG's intrinsic geometry — naturalWidth and naturalHeight, which the engine derives from the width/height attributes or the viewBox. An opaque white backdrop is painted first with fillRect(), then the rendered vector graphic is composited on top via drawImage(). Painting white underneath means any transparent regions in the source — the absence of paint in vector terms — become white in the bitmap. The final canvas.toBlob(..., 'image/png') call hands the composited RGBA buffer to the browser's native PNG encoder, which produces a lossless DEFLATE-compressed datastream.
Because the SVG is consumed in an image context rather than an inline document, it is subject to image-loading security rules: external references — remote fonts, images, or scripts — are not fetched, so the most reliable inputs are self-contained files where all styling is inline. Rasterizing this way is lossless in the pixel sense: antialiased edges are baked in by the renderer at the source resolution, which is exactly why you should export at the largest size you may need before switching to PNG.