Why Your SVG to PDF Export Rasterizes (and How to Stop It)

Print the SVG to PDF from a browser, or run it through a vector toolchain. Either way, the output can stay fully vector, because SVG and PDF are both path-based formats. The catch is that most of the common ways people do this rasterize part or all of the document without any error telling you it happened.

The interesting question isn't "how do I convert SVG to PDF." It's "how do I convert it without turning vectors into a bitmap, and what specifically breaks when I do." That's what this post covers.

Same model, different container

SVG and PDF both describe drawings as paths, fills, strokes, and transforms. Converting one to the other is closer to re-encoding the same instructions than redrawing the artwork. Compare that to SVG to PNG, where you're committing to a pixel grid permanently. A correct SVG to PDF conversion keeps every path as a path down to the anchor points, not as sampled pixels.

Whether you actually get that depends on the conversion route and what the SVG contains.

The browser print route, step by step

1. Open the SVG in a browser tab as real rendered markup, not as a linked image.
2. Trigger print, either via keyboard shortcut or programmatically:

window.print();

1. Choose "Save as PDF" as the print destination instead of a physical printer.
2. Save.

The browser's print pipeline renders SVG the same way it displays it on screen, so paths and (usually) text survive as vector data. What breaks isn't the print step, it's everything upstream of it.

The unit mismatch that crops your drawing

SVG's default unit is the CSS pixel at 96 dpi. PDF and print contexts think in physical units. Without an explicit page size, you inherit the browser's default (commonly A4 or Letter) with its own margins, and your artwork gets shrunk, centered, or cropped inside it.

The conversion is:

mm = px * 25.4 / 96

An 800 by 600 unitless SVG works out to roughly 211.67mm by 158.75mm (800 * 25.4 / 96 = 211.666..., 600 * 25.4 / 96 = 158.75). Set @page to that exact size with zero margin, and the PDF page becomes the artwork instead of a default sheet with the artwork floating inside it:

@page {
  size: 211.67mm 158.75mm;
  margin: 0;
}

Skip this and you get a PDF that renders fine on screen but exports tiny, off-center, or clipped. It's a page size problem, not a rendering bug.

Text-to-paths is a real trade-off, not a free upgrade

If a <text> element references a font that isn't available at print time, the browser substitutes something else, and line wraps, overflow, and spacing all shift with it. Converting text to paths sidesteps that entirely: every glyph becomes a vector shape, so layout is locked in regardless of what fonts exist on whatever machine opens the PDF later.

But converted text is no longer text. It doesn't select, it doesn't search, copy-paste from the PDF returns nothing useful. If the document needs to stay searchable, you have to solve font availability instead, you can't get both guarantees from the same export.

Inline everything or it silently vanishes

Images referenced by URL, external stylesheets loaded via <link> or @import, anything the print context can't resolve synchronously: none of it errors, it just doesn't appear. Convert linked images to base64 data URIs and fold external CSS into an inline <style> block before you print. Missing images in an otherwise-correct export is almost always this.

Filters and masks are the real rasterization trigger

This is the one that catches people who did the page size and fonts and inlining correctly. Filters, masks, clip paths, and blend modes commonly get flattened to a bitmap for just that region, even while the rest of the document stays vector. A Gaussian blur or a complex mask usually can't be expressed as PDF path data, so the renderer rasterizes that piece at whatever resolution the print pipeline picked. "My PDF is vector except this one blurred shape" is the expected outcome of using those effects, not a bug in your export.

Verifying the output is actually vector

Two checks, both fast:

• Zoom past 400 percent in a PDF viewer. Vector paths stay crisp at any zoom. Pixel edges or a soft stair-step mean that region was rasterized.
• Try selecting text with the viewer's text tool. If it highlights as text, it's still text. If nothing selects, it's paths (or wasn't text to start with).

Where SVG Lab's PDF export sits in all this

SVG Lab (the editor I built, at svglab.app) has PDF in its export menu next to SVG and PNG. The implementation is exactly the print-to-PDF route above: it opens a print-only window with the SVG inlined, computes an @page size from the document's own dimensions using the same px-to-mm math, then calls window.print() so the browser dialog handles the actual "Save as PDF" step. Worth saying plainly: this is 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 surfaces a status message telling you to allow pop-ups when that happens). Export is gated behind sign-in.

Quick answers

Does the conversion lose quality? Only where something rasterizes. Paths, fills, and strokes translate losslessly. Filters, masks, blend modes, and fixed-pixel rendering are the usual culprits when it doesn't.

Do I need to install anything? No. Any current browser can print an SVG to PDF via the built-in dialog. A CLI vector tool is only worth reaching for if you're batch-converting many files.

Why did I get a blank PDF? Check for a blocked pop-up window first if your tool opens one, then check for external stylesheets or images that didn't resolve in the print context.

Why did my text reflow? Font substitution: the referenced font wasn't available at print time. Fix the font availability, or convert text to paths and accept that it's no longer selectable or searchable.