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. 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.
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.
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. Its PDF export is the print-to-PDF route described above: it 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. The page size is pre-matched 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: it's a print-to-PDF flow, not a server-side converter, and because it opens a new window, a pop-up blocker can stop it (the app shows a status message telling you to allow pop-ups if that happens). Export requires being signed in. Try it at svglab.app.
FAQ
Does converting SVG to PDF lose quality?
Not if the conversion stays vector. Paths, fills, and strokes translate losslessly between the two formats. Quality loss happens specifically where something gets rasterized along the way, most often filters, masks, blend modes, or a document rendered at a fixed pixel size rather than exported as vector data.
Can I convert SVG to PDF without installing anything?
Yes. Any modern browser can open an SVG and print it to PDF using the built-in "Save as PDF" destination in the print dialog. No installation is required for that path. Command-line vector tools are an alternative if you need to batch-convert many files at once.
Why is my PDF blank?
The most common cause is a pop-up blocker stopping the print window before it opens, if the conversion tool uses that approach. Also check that the SVG doesn't rely on external stylesheets or images that failed to load in the print context, since those regions will simply be empty rather than showing an error.
Why did my text move or wrap differently in the PDF?
This is font substitution. The font referenced in the SVG wasn't available at print time, so the browser fell back to a different font with different letter widths and line heights. Either embed or install the correct font, or convert the text to paths before exporting, keeping in mind that converted text is no longer selectable or searchable.