SVG to PDF Converter
Turn SVG drawings into a PDF. An SVG has no pixels until something decides to draw it, so this asks you at what resolution to render rather than guessing, and it reads the size out of the viewBox when the file does not state one. Set the render scale high and line work and text stay crisp at any zoom. Nothing is uploaded.
- Nothing uploaded
- Works with no signal
- No sign up
- Searchable output
Nothing added yet. Each image becomes one page, in the order shown.
Page preview
Showing page 1.
Nothing here is uploaded. The images are read by this page, the PDF is assembled in memory, and the download comes from your own machine. Close the tab and it is all gone.
Your files never leave this device.The images are read by your browser, the PDF is built here in the page, and the download comes from your own machine. Nothing is sent to a server, so nothing is stored on one. Open the network tab in your browser tools and convert something: there is no upload request to see.
Drawn at the size you need
An SVG has no fixed pixel size, so it is rendered at whatever scale you choose. Higher scales produce sharper line work, and the effective resolution is shown for each one.
How to use this tool
Drop your SVG files onto the box at the top, or click it to browse. Each becomes a page, in the order the thumbnails show.
Render scale is the setting that matters here and nowhere else on the site, because an SVG has no pixels of its own. Four is a sensible default. Push it to eight for anything that will be printed large or zoomed into.
Then set the paper and margin as usual, and check the preview before downloading.
An SVG has no size until something decides one
Every other image format on this site arrives with a fixed number of pixels. An SVG does not. It is a set of instructions: draw a line from here to there, fill this shape. Those instructions can be drawn at any size, which is the whole point of the format.
That creates a practical problem the moment you put one into a PDF, because a PDF page holds pixels. Something has to decide how many. Left to itself a browser will apply a default that is usually far too small, and the result looks soft for no obvious reason.
So this tool asks rather than guesses. Render scale multiplies the drawing's declared size before it is rasterised: a 400 unit wide drawing at scale 4 becomes 1600 pixels across. More pixels means more file, and it means the drawing survives being zoomed into.
Reading the size out of the viewBox
Many SVGs, probably most of the ones exported from design tools, carry no width or height at all. They carry only a viewBox, which describes the coordinate space the artwork was drawn in.
Handed one of those, a browser falls back to a default replaced element size. Testing this before building the tool, a drawing designed at 400 by 300 reported itself as 200 by 150, half the intended size in each direction and a quarter of the pixels.
So where a file declares no size, the viewBox is parsed and its dimensions used instead, which is what the artwork was actually drawn against. The reader handles commas as well as spaces between the four numbers, copes with units such as millimetres in the width, and falls back safely on anything it cannot make sense of.
The practical result is that a viewBox only SVG comes out at the size you would expect rather than mysteriously blurry.
What you lose, said plainly
This conversion rasterises. The output is a picture of your drawing, not the drawing itself.
Text becomes shapes, so nobody can select it, search it or copy it out of the finished PDF. Line work stays sharp only up to the resolution you rendered at, and past that it softens like any other image. A true vector to vector conversion would keep all of that, but it needs the drawing rebuilt as PDF drawing instructions rather than pixels, which is a different and much larger piece of work.
For most uses, getting a drawing into a document someone can open, rendering at a high enough scale is indistinguishable from the real thing. It is worth knowing which one you have, though, particularly if the recipient expects to search the text.
A worked check you can repeat
Take a drawing with viewBox 0 0 400 300 and no declared width. The viewBox gives 400 by 300. At render scale 4 that becomes 1600 by 1200 pixels before it goes anywhere near the page.
The drawing is wider than it is tall, so with orientation left on match each image the page turns landscape: 841.89 by 595.28 points. A 10 mm margin leaves a printable box of 785.19 by 538.58. The drawing aspect ratio is 1.333 against a box of 1.458, so this time height is the limiting dimension. The drawing lands 538.58 points tall and 718.1 wide, which is 9.97 inches. Effective resolution is 1600 pixels across 9.97 inches, about 160 dpi, past the 150 dpi print threshold.
At render scale 1 the same drawing would be 400 pixels across those same 9.97 inches, about 40 dpi, and the tool flags it as low resolution because it would look obviously soft. Push the scale to 8 and it reaches 321 dpi. That spread, 40 to 321 from the same file, is the whole reason the control exists.

The size reader was checked against files declaring width and height, files carrying only a viewBox, viewBox values separated by commas rather than spaces, widths given in millimetres, files declaring neither, and malformed input. The page geometry was checked against an independent implementation.
Mistakes that catch people out
Leaving render scale at 1. On a viewBox only file that produces a small, soft image. Four is the sensible starting point.
Expecting selectable text. Everything becomes pixels. If the text must be searchable, this is not the route.
Relying on externally linked images or fonts. The page makes no network requests, so anything referenced by address will not appear, and missing fonts get substituted. Embed what must be there.
Pushing scale to 8 on a large drawing. Pixels grow with the square of the scale, so it gets very large very fast. Use it where it earns its place.
Forgetting the background. An SVG is transparent by default, so on a coloured page the drawing shows whatever is behind it. Choose a background unless that is what you want.
Common questions
Is my SVG uploaded anywhere?
No. The files are read by your browser, the PDF is assembled here on the page, and the download comes from your own machine. Nothing crosses the network, so there is nothing on a server to store or delete.
Will the result still be vector?
No, and this is the honest limitation. The drawing is rasterised into pixels at the resolution you choose. Text in the PDF will not be selectable and it will not stay sharp at unlimited zoom. Render scale decides how far you can zoom before that shows.
What render scale should I use?
Four is a good default and stays crisp at normal zoom. Use eight for something that will be examined closely or printed large. One matches whatever size the file declares, which is often much smaller than you want.
My SVG has no width or height. Does that matter?
Not here. Where a file declares no size, the size is read out of its viewBox instead, which is what the drawing was actually designed against. Without that step a browser would guess a small default and the result would look blurry.
Do fonts and external images come through?
Text renders using fonts available to your browser, so an SVG referencing a font you do not have will substitute another. Images linked to an external address are not fetched, because the page never makes network requests. Embed anything that must appear.
Does transparency survive?
Yes. SVG backgrounds are transparent by default and SVGs are embedded losslessly here, so pick a background colour unless you want the page showing through the drawing.
Related PDF tools and reference
Reference: The SVG specification, which defines the viewBox and sizing rules used here.
