An SVG is not a picture. It is a set of drawing instructions — move here, draw a curve, fill this shape with that colour. Nothing in the file has a resolution, which is why an SVG looks perfect at any size on a web page.
Converting it to a PNG means executing those instructions onto a specific grid of pixels. The interesting consequence is that you get to choose the grid, and that choice is genuinely free: a drawing rendered at four times the size is not an enlargement of a small render, it is a fresh render at that size, and it is exactly as sharp.
Pick the size the destination wants
Because rasterising at a larger size costs nothing in quality, the right output size is simply whatever the thing consuming it needs. A print shop asking for 3000 pixels and a content system that caps uploads at 300 are the same source file with two different renders — neither is a compromise.
This was worth measuring rather than assuming, and it was: a drawing rasterised at 4× has the same edge sharpness as the same drawing rendered natively at that size. So Filum makes the size a control — 1×, 2×, 4×, or an exact pixel width — rather than deciding for you.
The 300-pixel trap
Many SVGs, especially exports from design tools, carry no width or height attributes at all — only a viewBox describing the coordinate space the drawing was made in. This is deliberate and correct: it is what lets the drawing scale to its container on a web page.
It also produces one of the most common silent conversion failures on the web. Asked to display such a file, a browser applies a specification default and reports it as 300 pixels wide, regardless of what is inside it. A converter that trusts that number hands you a 300-pixel PNG of 900-pixel artwork and calls it a success — and because a 300-pixel PNG looks fine on screen, you often find out when it is placed somewhere and looks soft.
The correct source is the viewBox, which describes the size the drawing was actually made at. Filum reads that, and the size shown on screen before you convert is the size of the file you get.
Scripts, linked images, and other people's files
SVG has a reputation as a risky format because it is XML and can contain scripts. Worth being precise about what that means when you are converting one: an SVG loaded for rasterisation is handled in a static mode with no code execution, so a script inside it does not run. One case is refused rather than converted — an SVG with HTML embedded inside it, which browsers will not rasterise at all — and Filum names that refusal rather than failing obscurely.
The linked-image case is subtler and more interesting. An SVG can reference an image hosted elsewhere. Fetching it would complete the picture — and would also make your browser contact a server named inside a file someone else wrote, which is precisely the mechanism a tracking pixel uses to report that a document was opened. Filum does not fetch them, tells you before converting, and lists the addresses involved. The rest of the drawing converts correctly; if you need the linked artwork, embed it on export.
Fonts, animation, and choosing PNG over JPG
Text in an SVG is text, drawn at render time with whatever font is available. A font that exists only on the designer's machine will be substituted, and the text will look different. If it must be exact, convert text to outlines in your design tool before exporting — then it is geometry, not type. An animated SVG is captured as a single still frame.
PNG is almost always the right raster target for vector art: it is lossless, it keeps transparency, and flat colour with hard edges is exactly the content it compresses best. JPG is the wrong shape for this content and will show blocking around edges and text. Use SVG to JPG only when something downstream refuses PNG.
The rendering happens in your own browser and the PNG is built on your device. SVGs are usually source material — brand assets, design-tool exports, unreleased work — which makes them a poor thing to hand to a server.