What Changes When SVG Becomes PDF? viewBox, Units and Font Logic

SVG is a web graphics format: flexible, scalable, adapting to the screen. PDF is a page format: fixed, physical, tied to print. Even though the two share the same vector drawing model, that philosophical difference produces concrete consequences in conversion. This article explains those differences and why some SVGs convert to PDF at unexpected sizes.

Two different notions of a "page"

In PDF a page is physical. Every page object has a MediaBox, and that's a fixed rectangle in points. An A4 page is 595 × 842 points, always, everywhere. Content is placed directly into that coordinate system. There's no such concept as "fit to screen" — the viewer zooms but the page itself doesn't change.

In SVG a "page" is relative. An SVG has no intrinsic size; the content is defined in a coordinate system and that system can be scaled into any viewport. The same SVG file can be shown 100 pixels wide in one place and 1000 pixels wide in another, and both are correct.

That philosophical difference forces a decision during conversion: when placing a flexible graphic onto a fixed page, which scale gets used?

viewBox: SVG's coordinate system

The viewBox attribute takes four numbers:

<svg viewBox="0 0 595 842">

Those are, in order: minX, minY, width, height. The meaning: "my content is defined in an area 595 units wide and 842 units tall starting at (0,0)."

All the coordinates inside are expressed in that system. If a rectangle says x="100" y="200", that's in viewBox coordinates.

viewBox is not a physical measurement. It only defines the internal coordinate system. How much space that system actually occupies is determined by width and height.

width/height: the display size

<svg width="210mm" height="297mm" viewBox="0 0 595 842">

In this file the content is defined in a 595 × 842 unit coordinate system and that system is scaled into a 210 × 297 mm area. So 1 user unit works out to about 0.353 mm — which is exactly 1 point (1/72 inch = 0.3528 mm).

Now consider the same content with a different width:

<svg width="105mm" height="148.5mm" viewBox="0 0 595 842">

The content is the same but shown at half scale — A5 size.

Unit ambiguity: the most common source of trouble

The problem starts when width and height are written without units:

<svg width="595" height="842" viewBox="0 0 595 842">

That leaves the question "595 what?" unanswered. There are two different interpretations with a 33% difference between them:

| Interpretation | 1 unit | 595 units | |---|---|---| | PDF/print convention: points | 1/72 inch | 210 mm (A4 width) | | Web/CSS convention: pixels | 1/96 inch | 157 mm |

Converters generally use the point interpretation and give the right result. But SVGs coming from a web context (produced by a charting library, saved by a browser tool) can contain values produced on a pixel assumption, and then the resulting PDF comes out larger than expected.

Worse still, when width/height are absent entirely:

<svg viewBox="0 0 800 600">

In that case the converter is guessing completely. Some treat the viewBox values as points, some fit to a default page size, some assume CSS pixels.

The fix is simple: before converting an SVG to PDF, open the file in a text editor and write the width and height values with physical units:

<svg width="210mm" height="297mm" viewBox="0 0 595 842">

That single edit eliminates the ambiguity entirely.

preserveAspectRatio: what happens on a ratio mismatch

If the viewBox ratio doesn't match the width/height ratio, the preserveAspectRatio attribute determines what happens. The default value is xMidYMid meet: the content is fitted into the area preserving its ratio and centered, with blank space left over.

The slice value does the opposite: the area is filled completely and the overflow is clipped.

In PDF conversion that shows up as unexpected blank edges on the page or clipped content. If there's a mismatch, equalizing the viewBox and width/height ratios is the cleanest solution.

Fonts: a fundamental philosophical difference

This is the most important practical distinction between the two formats.

PDF embeds fonts. The format's reason for existing is that the document looks the same everywhere. The only way to guarantee that is putting the glyph data of the fonts used into the file. The font you see when you open a PDF is a font the file carries inside itself.

SVG generally doesn't embed. It writes font-family="Roboto" and expects that font to be present in the display environment. On the web that's solved by loading a font file with CSS @font-face — but that information may live in the page's CSS rather than in the SVG file itself.

What happens during conversion depends on whether the converter can reach that font:

• If it can: the font is embedded into the PDF and the text stays real text. Selectable, searchable, accessible.
• If it can't: it falls back to a similar font. Letter widths change, alignment shifts, and long lines can overflow or shorten.

The insidious thing about that second case is that the result looks wrong but plausible. You don't notice at a glance; only when you put it side by side with the original do you see the alignments have shifted.

The definitive fix: converting the text to outlines (paths) in the program that produces the SVG. Every letter becomes a vector shape and the font dependency drops to zero. The cost is that the text becomes unselectable and unsearchable.

Color: no way out of RGB

SVG is natively RGB. You write fill="#3366CC" or fill="rgb(51,102,204)". There's no such concept as CMYK.

PDF, by contrast, supports CMYK, spot colors and ICC color profiles — because it was designed for print.

In SVG to PDF conversion the colors carry over as RGB. That's no problem for screen use, but it's a shortcoming in a file headed for print: the print shop wants CMYK and, receiving an RGB file, does the conversion itself, so the result can differ from what you saw. Vivid greens, oranges and rich blacks in particular come out unexpectedly.

If the print job is serious, converting to CMYK in a design program after the conversion is necessary.

Filters and rasterization

SVG's <filter> element offers powerful effects: Gaussian blur, drop shadow, color matrix, lighting, turbulence.

PDF's transparency and effect model is different and most of those filters have no direct equivalent.

The converter has two options:

1. Use an approximate equivalent. That's possible for simple alpha transparency and some blend modes.

2. Rasterize that region. The filtered area is rendered into an image and placed into the PDF as pixels.

The second gives a visually correct result but loses vector sharpness. When you zoom into the PDF that region pixelates. In print it appears as a low-resolution area.

That's why it's safer to avoid filters in SVGs headed for print and to imitate shadow and blur effects with vector means.

Everything dynamic gets frozen

SVG is a web technology, and that has consequences:

| In SVG | In PDF | |---|---| | SMIL animation | The first frame or initial state | | CSS animation / transition | Frozen | | :hover styles | Not applied, the normal state remains | | JavaScript-generated content | Carried if the converter reads the DOM, not if it reads the file | | <foreignObject> (embedded HTML) | Usually lost | | External CSS file | May not be applied |

The last two rows matter: if your SVG depends on an external CSS file or on JavaScript, the file is incomplete on its own. Before converting, you need to inline the styles into the SVG (inline style attributes or a <style> block).

What you gain

You don't only lose in the conversion; PDF brings things too:

• Font embedding: the file becomes self-sufficient.
• Multiple pages: several SVGs can be collected in one document.
• Print control: page size, orientation and margins are defined.
• Document properties: metadata, bookmarks and digital signatures become possible.
• Universal openability: it behaves as expected on every device.

In summary

SVG works in a flexible, relative coordinate system; PDF rests on fixed, physical page logic. Most conversion problems stem from that difference: when no width/height unit is specified the page size is left to guesswork (the points-vs-pixels distinction creates a 33% difference), fonts aren't embedded in SVG so they depend on the converter's access, colors can't escape RGB, and complex filters lead to rasterization that loses vector sharpness. All of these problems can be solved in advance: write physical units, convert text to outlines, avoid filters, and plan the color conversion as a separate step if it's headed for print.