What Is SVG? Why Is It So Similar to PDF, and Where Do They Diverge?

PDF to SVG conversion is one of the most "direct" conversions between formats — because the two formats are really members of the same family. This article looks at their shared roots, where they map exactly, and where they diverge.

A common ancestor: the PostScript imaging model

Both formats use an imaging model derived from PostScript, the page description language Adobe developed in the 1980s. That model's core ideas are:

The concept of a path. Shapes consist of paths defined with straight line segments and Bézier curves. A path can be open or closed; it can be filled, stroked, or used as a clipping area.

The painter's model. Drawings are applied in order and later drawing lands on top of earlier drawing. Like applying paint on a canvas.

Graphics state. Settings like color, line width and transformation matrix are held in a state stack; they can be saved and restored.

Transformation matrices. Scaling, translation, rotation and skewing are expressed with six-element affine transformation matrices.

Thanks to that commonality, most of PDF's drawing commands have a direct equivalent in SVG:

| PDF command | SVG equivalent | |---|---| | m (moveto) | M (path data) | | l (lineto) | L | | c (curveto) | C (cubic Bézier) | | re (rectangle) | <rect> or a path | | f (fill) | fill attribute | | S (stroke) | stroke attribute | | W n (clip) | <clipPath> | | cm (transform) | transform attribute | | q/Q (save/restore state) | <g> grouping |

The converter's job is essentially performing that mapping. That's why PDF→SVG conversion is far more reliable than, say, PDF→Word conversion; the latter requires format guesses while here it's mostly direct translation.

The first divergence: the coordinate system

PDF comes from print tradition. The origin is at the page's bottom left corner and the y axis increases upward. That's the same as the Cartesian system from math class and is natural for thinking about paper dimensions.

SVG comes from screen tradition. The origin is at the top left corner and y increases downward. That's the standard approach in computer graphics.

Converters solve this with a transformation matrix: they flip all the content on the y axis and shift it down by the page height. As a user you don't notice, but if you open the SVG file as text you may see a transform like this on the root element:

transform="matrix(1,0,0,-1,0,842)"

That means "flip the y axis and shift down 842 units" — 842 being the height of an A4 page in points.

The second divergence: units

PDF uses the point: 1 point = 1/72 inch. An A4 page is 595 × 842 points. That unit is standard in the print world.

SVG defines user units through the viewBox attribute and isn't tied to a physical measurement. Units like pixels, millimeters and inches can be specified with the width and height attributes, but that isn't mandatory.

In conversion, PDF's point values are usually taken directly as SVG user units. The result is that the page's proportions are preserved but the physical size information can become ambiguous. If you're preparing an SVG headed for print, you need to specify the width and height values explicitly in millimeters.

The third divergence: fonts

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

PDF embeds fonts. A PDF can (and usually does) carry the glyph data of the fonts it uses inside itself. That guarantees the file looks exactly the same everywhere — it's the format's reason for existing.

SVG generally doesn't embed. A standard SVG file says font-family="Arial" and expects that font to be present on the reader's system. If it isn't, the browser falls back to a similar font.

The consequence: when you carry text from a PDF into SVG as text, there's a chance the original font isn't on the reader's machine. Letter widths change, lines overflow or shorten, alignment breaks. With documents using corporate or commercial fonts that's practically certain.

There are three solutions:

1. Convert the text to outlines. Every letter becomes a <path>. The appearance is guaranteed but the text is no longer text — it can't be selected or searched, screen readers can't read it, and the file grows noticeably.

2. Embed the font. With CSS @font-face you can put base64-encoded font data inside the SVG. Both appearance and accessibility are preserved but the file grows and the font license may not permit it.

3. Fall back to a web-safe font. If a common font is used (Arial, Times New Roman), the risk is low.

In practice outlines are preferred for logo and graphic work, and embedding or text for text-heavy content.

The fourth divergence: color space

PDF supports CMYK natively. Because it was designed for print, colors can be defined with cyan-magenta-yellow-black components. Spot colors (separate inks like Pantone) and ICC color profiles can also be defined.

SVG is RGB-based. There's no such concept as CMYK. You write fill="#RRGGBB" or fill="rgb(r,g,b)".

In conversion, CMYK values get converted to RGB, and that's a lossy conversion. The two color spaces have different gamuts (the range of colors they can cover); some CMYK colors have no exact RGB equivalent. The most obvious differences appear in deep reds, navy blues, oranges and rich blacks.

If corporate colors have to match exactly, you'll need to correct the color values in the SVG by hand after conversion, using the RGB values from your brand guide.

The fifth divergence: transparency and effects

PDF's transparency model is quite advanced: alpha transparency, blend modes (multiply, screen, overlay...), soft masks, transparency groups.

SVG has transparency support too (opacity, fill-opacity, <mask>, <filter>) but the models don't map exactly. Some PDF blend modes have no direct SVG equivalent, and some soft mask structures are processed differently.

The result: with design files containing advanced transparency effects there can be visual differences after conversion. Simple alpha transparency causes no trouble.

The sixth divergence: structure and purpose

PDF is multi-page and a document format. The page tree, bookmarks, form fields, annotations, metadata, digital signatures — all of those belong to the concept of a document.

SVG is single-"page" and a graphics format. There's no concept of multiple pages. There are no document features like bookmarks, form fields or annotations.

In conversion all of those are lost:

| PDF feature | In SVG | |---|---| | Page structure | Each page a separate file | | Bookmarks | Lost | | Form fields | The appearance remains, the function goes | | Annotations | Usually lost | | Hyperlinks | Some converters carry them as <a> | | Metadata | Lost | | Layers (OCG) | Usually flattened | | Digital signature | Lost |

In exchange, SVG has capabilities PDF doesn't: styling with CSS, interaction with JavaScript, SMIL or CSS animation, and programmatic access through the DOM.

Why print shops don't want SVG

Because of three gaps:

No CMYK. Printing presses work in CMYK; an RGB file creates color management uncertainty.

No bleed or crop marks. PDF has BleedBox and TrimBox; SVG has no such concept defined.

No color profile management. ICC profiles can't be embedded.

That's why print shops want PDF, and especially the PDF/X subprofiles. SVG was designed for the web and screens, PDF for print and document sharing.

In summary

PDF and SVG are two vector formats derived from the same PostScript imaging model, and their drawing commands map largely one to one — which explains why the conversion is so reliable. Where they diverge produces practical consequences: their coordinate systems are inverted (the converter compensates), PDF embeds fonts while SVG generally doesn't (the source of the text-or-outlines decision), PDF supports CMYK while SVG is RGB-based (color shift), and PDF is a document format while SVG is a single-page graphics format (bookmarks, forms and multi-page structure are lost). The right format choice depends on where the output is going: SVG for the web and design, PDF for print and document sharing.