Exporting layout as SVG (browser destination)

I’m attempting to export a PCB layout as SVG with the intent of displaying it in a browser but failing.
I’m selecting ‘board area only’ and expecting to see my board outputted to some sort of viewable screen resolution (eg 1 inch = 72dpi) in a viewbox showing just the board area.

The resulting file does not display as I expected though! It look suspiciously like the board is represented too small to render in a viewbox that represents the entire board environment dimensions. The file is viewable in InkScape which displays it as one might expect, so not invalid SVG code.

I’m using KiCAD v6.0.0 on Windows 11 and viewing the SVG in Firefox.

Wondering (hoping) I’ve gotten something simple setup incorrectly and someone can point me in the right direction.

A little experiment:

Another experiment:

The experiment:

A little experiment:

Another experiment:

So that does not work. This forum software does not accept svg in posts.

There are (at least?) two ways to generate .SVG output from Pcbnew.
Pcbnew / File / Export / SVG
Pcbnew / File / Plot / Plot format: SVG

I don’t know much about the implementation of .SVG (although I like it as a portable vector formart that should be parsable by any decent web browser).

A workaround that sometimes works is to open the file in another program (such as InkScape) and then save it again.

The svg header includes the board dimensions in cm and the view box dimensions (actually measured in nm) but without any units. This board is actually 1" high (2.54cm) and Safari scales it to a svg image of 96px high which seems right.

If you want it to be larger, it is probably simplest to specify it as a object and define your width there or in a css. e.g.

<object data="/Users/johnpateman/EDA_Workspace/Projects/Tiny85Spark/Plots/Tiny85Spark-F_Cu.svg" width="1000" />

1 Like

I had a quick look at the header of a .SVG generated by Pcbnew:

  width="29.700220cm" height="21.000720cm" viewBox="0 0 297002200 210007200">

And the width and height look suspiciously much like an A4 page.

When viewed in some image viewer, there is also a big empty border around the PCB (The PCB is from a KiCad Demo Project, ecc83-pp).

I’ve experimented a bit with changing the the “viewbox” settings with a text editor. Setting them to:

  width="29.700220cm" height="21.000720cm" viewBox="110000000 90000000 112000000 92000000">

Gives the result:

So this definitely works, but it’s very cumbersome to do it this way and there surely are better ways to do this.

Then I changed the paper size in Pcbnew / file / Page Settings. Set it to a custom size of 60*70mm:

And it looks like:

(Note that the paper size is now smaller then the title block)

The big empty borders are gone now, and this confirms that KiCad just exports the whole page.

1 Like

@paulvdh The svg export dialogue also now gives the option of ‘board area only’ at least on KiCad6 (which is what I used) and the op mentioned. Otherwise, you are right - the page is hardcoded to A4. The python interface to the plot svg routines has also changed between 5 and 6 and the scaling does something different now.

1 Like

Duh, indeed. Oops.

Pcb Editor / File / Export / SVG has:

… and verified that it works:

1 Like

I’ve made far too many SVG’s and SVG based PCB’s to ignore this post…

SVG is simple, once user understands the basic’s of SVG’s.
Setting aside Kicad’s implementation and usage, the following should help… Checkout W3Schools.com

Here’s quick info…
svg info.rtf (15.9 KB)

Screenshot from info I posted at another site…

Hand-Coded PCB with V-Cut

1 Like

Thanks for the responses. I’ve made a quick ‘minimum sample’ file (x2 resistors, trace and edge cuts) to retest and definitely seeing some weirdness in comparison to the samples others have posted. I tried exporting via ‘plot’ too with same odd results. screenshot of my outcome:

SIGH I thought I had tested in another browser but looks like I hadn’t.
SVG renders as expected in Microsoft Edge so looks like a Firefox problem.

Thank you again for the responses. They all helped me rethink and persevere with trouble-shooting.

…For the record: On further testing (reminder, I’m using Windows 11) it looks like Both browsers fail to render correctly with the very big viewbox dimensions.

Look at the Width and Height and Viewbox in my posted SVG info and look at Your posted SVG (the blue highlighted stuff), you’ll see a problem… And, should dial-in the solution from that…

You can search for Viewbox, here’s a link to the page.… and screenshot of Section8 Contents

After you spend hours reading and testing, thus learning the basics of SVG, you may come away knowing a ViewBox is not really needed to produce a correct result in Browsers/other

Programs that use SVG are dependent on the folks coding the program. Below is a homemade example of a Basic Rectangle with a Rectangle cutout (done via usng SVG’s “intrinsic” subtraction. Comments are included.

Try it in browser of interest (try adding a ViewBox with correct Dimension’s…)

EDIT #1: It can get confusing, especially when considering various programs/browsers often require a specific SVG format/Version (example below for Exporting SVG from EZdraw). There are other standards, too and of additional Importance is the ‘Format’ of how the Data is expressed ( " or ’ quotes). Some programs except both ways, some don’t.

And, for Clarity of ViewBox data (by example): a Width of 5.555" is: 5.555in x 72dpi = 400px, that’s the value to put in the ViewBox for the width… Thus, stressing the importance of knowing the DPI of the viewing program (or, you get a incorrectly scaled image… Fun, isn’t it :rofl:

EDIT #2: Out of curiosity, I loaded Kicad Exported SVG into FreeCAD and was prompted to select DPI (screenshot below). I don’t remember any other Program being that smart about SVG (it’s a Wild-West world when it comes to SVG…). FreeCAD seems to expect that Inkscape was used to create SVG’s…

Time for me to move on from this post…

Screen Shot 2022-01-12 at 9.25.23 AM

<?xml version="1.0" standalone="no"?>
<!-- Hand Coded -->
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" 
width="500" height="400">

<!-- Rectangle with cutout. Rectangle points go CW, Cutout goes CCW. That makes it -->
<!-- NOTE: The cutout uses a MoveTo for closing it, instead of "Z" close path-->
<!-- that ensures Fritzing recognizes it, or it will be left 'Open' -->
<path d="M0,0 L500,0 L500,400 L0,400 L0,0 Z
M300,100 L300,300 L400,300 L400,100 L300,100" fill="green" stroke-width="3" />



@BlackCoffee I’ve made a ‘minimum sample’ SVG outside KiCad to test further. Edge is also failing on this test, so looking like a Windows or local-machine issue :sob:

…whilst technically not a KiCad bug I’m wondering if I should log it as one --anyone have recommendations/suggestions on this thought?

code for anyone who cares to cross-check
Small scale SVG:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<svg width="5cm" height="5cm" viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">

<rect x="0" y="0" width="100" height="100" style="fill:#00ff00"/>

<rect x="0" y="0" width="10" height="10" style="fill:#ff00ff"/>

<rect x="20" y="0" width="10" height="10" style="fill:#ff00ff"/>

<rect x="40" y="0" width="10" height="10" style="fill:#ff00ff"/>

<rect x="60" y="0" width="10" height="10" style="fill:#ff00ff"/>

<rect x="80" y="0" width="10" height="10" style="fill:#ff00ff"/>


Large scale SVG:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<svg width="5cm" height="5cm" viewBox="0 0 100000000 100000000" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">

<rect x="0" y="0" width="100000000" height="100000000" style="fill:#00ff00"/>

<rect x="0" y="0" width="10000000" height="10000000" style="fill:#ff00ff"/>

<rect x="20000000" y="0" width="10000000" height="10000000" style="fill:#ff00ff"/>

<rect x="40000000" y="0" width="10000000" height="10000000" style="fill:#ff00ff"/>

<rect x="60000000" y="0" width="10000000" height="10000000" style="fill:#ff00ff"/>

<rect x="80000000" y="0" width="10000000" height="10000000" style="fill:#ff00ff"/>


I’m not sure what you mean by “Edge” failing. The output looks correct with respect to your posted xml.

As far a result in Firefox, let me get back to you - need to deal with something presently… stay tuned

As in Microsoft Edge browser is failing to display the SVG correctly - Unless I’ve made a mistake in my code or misunderstand how viewbox works ALL 4 of the graphics should look identical. Ie, the same size with 5 small squares across the top and a big square that covers the entire graphic in the background.

Sorry it took so long (house maintenance stuff…)

You’re mixing units.
Your output graphic is doing what you’re telling it to do. Just need to tell it to do the correct thing.

px = dots and ALL SVG is based on DOTS/INCH, Thus, need to convert from Metric to Inch and it’s best to Not mix units or DPI (you can mix units but, if so, clarify them with unit designator and, don’t hope too much for graphic readers (i.e., Edge, Firefox…etc) to get it right. They’ve gotten better but, not all are there, yet.

Thus, Best to stick with one way of doing it (or go through the PITA of calculating and fixing errors and discovering what’s wrong…)

Once you get your graphics looking as desired (using INCH and PX), then you mess with trying out different approaches.

ADDED: Again, you don’t need a viewbox but, if using one, be sure to get the parameters correct!

Google: SVG viewBox

ADDED: I forgot to comment on ‘Edge’. I don’t use it (I have Mac’s) but, you can include Conditional Statements in your XML/SVG to take care of different Browser/App needs. That way you control the stuff that makes all look good and work well for Browsers…etc.

That’s all about ‘XML Coding’ and this forum is not the place to learn that and get the kind of help you may need (naturally, many good sites out there, I referenced a couple…)

Thanks for the input @BlackCoffee. I agree that including cm dimensions and viewbox complicate things but that is how KiCad exports SVGs so I’m trying to troubleshoot why they look broken with those parameters.

I’ll keep tinkering on it and in the mean time accept KiCad SVG output requires additional post processing for my needs.

@j0ono0 how did you fix Kicad output for Firefox? I could not find a single possible way to fix it. Even manually, I could not fix.

I am attaching here 2 files. One exported from Kicad 5 that works on Firefox, and another exported from Kicad 6 that does not work on Firefox.


kicad6_board-37-F_Silkscreen (this will be blank if reading this page on Firefox)
here vias are not well formed

This is a preview on a gray bg.

Unfortunately, I don’t have other files. But it also looks like Kicad has an issue exporting generating vias. At least on my svg files

Then I was able to fix it to show it properly on Google Chrome only since Firefox is showing a blank image.

rsvg-convert -a -w 1096 -f svg file.svg > file_fix.svg

I could workaround fixing svg files for Firefox (and Chrome too) with this command, by dividing all values inside d= propperty by 1000

perl -i -pe 's{(?<![\d#])(\d{5,}(?:\.\d+)?)(?!\d)}{sprintf("%.1f", $1/1000);}ge' board.svg

The command is not pretty smart yet, but I was able to generate a working svg for Firefox for the first time.

@leoheck I didn’t solve my SVG export problem. In fact since last posting here it got worse. I installed Chrome to discover the problem exists in that browser too - at least in Windows.

For my needs I want the option of linking to an SVG rather than embedding so post-processing an SVG is not ideal --It’s a neat idea though, I’ll definitely be keeping that option on hand!

Edit: I noticed the issue was closed over at gitlab – BUT – A preexisting one appears to have made good progress: Draft: Change SVG Exporter units to 1mm (!974) · Merge requests · KiCad / KiCad Source Code / kicad · GitLab

Yeah, it was closed. This is not good at all.

So, this workaround is just to validate where the issue is. I spent a lot of time trying to find what was causing svg to not be rendered on Firefox.

Kicad 5 generates values with less than 5 digits. Now, Kicad 6 is generating values with 8 or 9 digits. So after a bunch of tests I could reduce the issue. Now I know it is related with these values.

So, why Kicad 5 was doing something that Kicad 6 is not doing? Devs could divide values by 1000 and it will fix the issue.