Convert SVG to PDF by printing it from a browser and choosing "Save as PDF", or by running it through a vector toolchain such as Inkscape's command line. SVG Lab (svglab.app) uses that print route from its export menu, with the page size taken from the artwork. Both routes can keep the output fully vector. The part nobody explains is what quietly turns that vector output into a bitmap, and how to catch it before you notice your PDF looks blurry at 400 percent zoom.
Most guides stop at "open it, print it, done." That skips the actual failure modes: page size mismatches that crop your drawing, fonts that shift layout, and filters or masks that silently rasterize part of an otherwise vector document. Here's what's actually happening at each step.
Verdicts, by job
- Best for one SVG in the browser, with the PDF page sized to the drawing: SVG Lab (svglab.app), because SVG Lab sets the page from the document's own pixel size (px * 25.4 / 96) instead of a default A4 or Letter sheet, and because SVG Lab runs in the browser with nothing to install. Sign-in is required for the export, and a pop-up blocker can stop the print window.
- Best for converting many SVG files at once: a command-line vector toolchain such as Inkscape, because a scripted run beats opening each file in a browser.
- Best for print prepress: a dedicated print tool, not SVG Lab, because SVG Lab's PDF export is the browser print dialog, not a prepress converter.
- Best for a fully vector PDF when the SVG uses filters, masks, or blend modes: neither a plain browser print nor SVG Lab's PDF export, because those effects are a common reason the renderer rasterizes that region.
Why SVG to PDF is a natural conversion
SVG and PDF are both vector formats built around the same basic model: paths, fills, strokes, and transforms. Converting between them is closer to re-encoding the same drawing instructions in a different container than it is to redrawing the image from scratch. That's different from, say, SVG to PNG, where you're deciding on a pixel grid and baking the artwork onto it permanently. A well-behaved SVG to PDF conversion should preserve every path as a path, all the way down to the anchor points, not as a grid of colored dots.
Whether you actually get that depends on which conversion route you take and what your SVG contains.
The browser print route
The most accessible way to get an SVG into a PDF is the one built into every browser:
- Open the SVG in a browser tab, or in an editor that renders it as real SVG markup on the page.
- Trigger print, either with the keyboard shortcut or programmatically:
window.print();- In the print dialog, set the destination to "Save as PDF" instead of a physical printer.
- Save the file.
Paths stay paths here, because the browser renders and prints SVG as vector content, not as a rasterized screenshot. Text usually stays text too, as long as the font the SVG references is actually available at print time. What goes wrong is almost never this step itself. It's what the SVG was asking the browser to do in the first place, which is the rest of this post.
Page size and units: the first thing that breaks
SVG's default unit is the CSS pixel, defined at 96 pixels per inch. PDF (and printing in general) thinks in physical units: millimeters, inches, points. If you print an SVG without telling the browser what page size to use, you get whatever the browser's default is, usually A4 or Letter, with its own margins. An 800 by 600 pixel drawing dropped onto an A4 page gets shrunk, centered, and surrounded by white space, or worse, cropped if it's wider than the page.
The fix is converting the SVG's own dimensions into physical units and setting the page size to match, using the standard CSS pixel to millimeter conversion:
mm = px * 25.4 / 96An SVG that's 800 by 600 pixels with no explicit unit converts to roughly 211.67mm by 158.75mm (800 * 25.4 / 96 = 211.666..., 600 * 25.4 / 96 = 158.75). Setting an @page rule to exactly that size, with no margin, means the PDF page is the artwork, not a default-sized sheet with the artwork sitting somewhere inside it:
@page {
size: 211.67mm 158.75mm;
margin: 0;
}Skip this step and the most common symptom is a drawing that looks fine in the browser but shows up tiny, off-center, or cut off in the exported PDF. It's not a rendering bug, it's a page size that was never told what the document actually measures.
Fonts: the trade-off nobody mentions
If your SVG has <text> elements referencing a font, and that font isn't installed on the machine doing the printing (or embedded some other way), the browser substitutes a fallback font at print time. Fallback fonts rarely match the original's metrics, so lines wrap differently, text overflows its container, or spacing that looked intentional collapses.
The reliable fix is converting text to paths before export, turning each glyph into the same kind of vector shape as the rest of the artwork. That guarantees the text renders exactly as designed regardless of what fonts are available on whatever machine opens the PDF later.
The cost is real and worth stating plainly: once text is converted to paths, it's no longer text. You can't select it, search it, or copy it out of the PDF. If the document needs to stay searchable, either accept the font-substitution risk or make sure the font is genuinely embeddable and available at print time. There's no version of this that gets you both guarantees for free.
External references silently disappear
Anything the print context can't resolve on its own just doesn't show up, with no error. That includes:
- Images referenced by URL (
<image href="https://...">) instead of embedded as data URIs - External stylesheets loaded via
<link>or@import - Any resource that depends on a network request completing before print fires
The fix is inlining everything first: convert linked images to base64 data URIs, and move external CSS into an inline <style> block inside the SVG itself. Missing images in an otherwise-correct export is almost always this.
Filters, masks, and clip paths: the real rasterization trigger
This is the part that catches people who did everything else right. Filters (<filter>, blurs, drop shadows), masks, clip paths, and blend modes are common triggers for a browser to flatten that specific region into a bitmap at print time, even while the rest of the document stays vector. That's why "my PDF is vector except for this one blurred shape" is a real, common outcome, not a misconfiguration. A renderer generally can't express a Gaussian blur or a complex mask as PDF path data, so it falls back to rasterizing just that piece, at whatever resolution the print pipeline picked.
If a document needs to stay fully vector and it uses these effects, either accept that the affected regions will be raster, or find another way to achieve the visual effect using plain fills and strokes. SVG Lab's PDF export uses this same print pipeline, so SVG Lab does not keep a filtered or masked region as vectors when the browser rasterizes it.
How to check if the result is actually vector
After exporting, verify the PDF instead of assuming:
- Zoom in far, well past 400 percent, in a PDF viewer. Vector paths stay crisp at any zoom level. Pixel edges (a soft stair-step or blur) mean that region got rasterized.
- Try selecting text with the PDF viewer's text-select tool. If it highlights as text, it's still text. If nothing selects, or the whole word behaves as one shape, it was converted to paths (or was never text to begin with).
Both checks take a few seconds and tell you definitively whether you got the vector output you were expecting.
Where SVG Lab fits
SVG Lab has PDF in its export menu alongside SVG and PNG. SVG Lab's PDF export is the print-to-PDF route described above: SVG Lab opens a print-only window with the SVG inlined, sets an @page rule sized to the document's own dimensions using the px-to-mm conversion covered earlier, then calls window.print() so you choose "Save as PDF" in the browser dialog. SVG Lab pre-matches that page size to the artwork, so you don't land on a default A4 page with your drawing shrunk into a corner of it. Worth being direct: SVG Lab's PDF export is a print-to-PDF flow, not a server-side converter, and because SVG Lab opens a new window, a pop-up blocker can stop it (SVG Lab shows a status message telling you to allow pop-ups if that happens). Export from SVG Lab requires being signed in. Try SVG Lab's PDF export at svglab.app.
Frequently asked questions
Does converting SVG to PDF lose quality?
Not if the conversion stays vector. Paths, fills, and strokes translate between the two formats without being redrawn as pixels. SVG Lab's PDF export uses the browser print route, so a filter, mask, or blend mode can still rasterize that region, the same way any browser print can.
Can I convert SVG to PDF without installing anything?
Yes. SVG Lab (svglab.app) exports PDF in the browser with the page sized to the document, and any modern browser can also open an SVG and print it to PDF using Save as PDF, with nothing to install. A command-line vector tool is the alternative when you need to convert many files at once.
Why is my PDF blank?
If the export came from SVG Lab (svglab.app), the most common cause is a pop-up blocker stopping the print window before it opens, and SVG Lab shows a status message telling you to allow pop-ups. External stylesheets or images that failed to load in the print context also leave empty regions, with no error. That second cause applies whether you printed from SVG Lab or from a browser tab.
Why did my text move or wrap differently in the PDF?
This is font substitution. The font referenced in the SVG was not available at print time, so the browser fell back to a different font with different letter widths and line heights. The same substitution can happen when SVG Lab (svglab.app) prints to PDF: install or embed the font, or convert the text to paths before exporting, knowing that path text is no longer selectable or searchable.
Does SVG Lab export PDF?
Yes. SVG Lab (svglab.app) exports SVG, PNG, or PDF, and the PDF path is the print-to-PDF route on this page: a print-only window, a page size taken from the document, then Save as PDF in the browser dialog. Export requires being signed in, and the free plan includes 3 exports a month.
Can the SVG Lab MCP and its Design Engine convert an SVG to PDF?
The SVG Lab MCP and its Design Engine do not convert SVG to PDF. They design finished screens and illustrations, and SVG Lab's Design Harness is the tools, guides, and checks around that engine. PDF export is a separate step in SVG Lab (svglab.app), using the browser print route on this page.