It’s not the same:
- This is exported data, not the raw underlying data structure. The underlying data structure may change for any new major release (LibrePCB performs migration of old project files automatically, but you will have to adjust your script then too to keep it working with a new file format). The exported data however is intended to be stable across major versions (only new data added from release to release, never removed).
- It is all in a single file, not spread across many files like the raw data. So it’s way easier and faster to parse.
- It’s JSON, not custom S-Expressions, so you can use any random JSON parser for it.
And it provides some advantages over a pure Netlist format:
- It contains the UUIDs in addition to the names, so you have much more information (e.g. you can detect a resistor by its UUID rather than relying on some name matching).
- We have control over the format, so we can add any additional data that might be useful for some tasks.
As far as I can see, KiCad also invented their own netlist format (no surprise, as there is no standard for it). It would be really strange if LibrePCB exported KiCad netlists 
If there is any kind of standard netlist format, or at least a format which is supported by a lot of different tools, I am not against implementing this in LibrePCB. But so far I am not aware of any such format. Using the JSON is therefore a very flexible intermediate format which can easily be converted into any other netlist format. With the only downside that it needs a small converter tool to do it.
This is what ChatGPT says about netlist formats:
Common Netlist Formats
Legacy / Interchange Formats (very common in converters)
Protel (Protel 1 / Tango)
-
Often called:
-
Used by early Protel / Tango PCB tools
-
Example style (like TinyCAD output):
[
R1
RESISTOR
10k
]
(
NET1
R1-1
U1-3
)
-
Very widely supported as an import/export format
Simple to parse
Multiple variants exist
TinyCAD output = this family
OrCAD PCB II (often called “OrcadPCB2”)
-
One of the most widely supported legacy formats
Used by early OrCAD PCB tools
Typical style:
( R1 1 NET1 )
( U1 3 NET1 )
-
Sometimes appears as:
NET1 R1-1 U1-3
-
Extremely common in EDA conversion tools
Still used as a “lowest common denominator”
EDIF (Electronic Design Interchange Format)
-
Standardized format (ANSI/EIA-548)
Very verbose, LISP-like syntax:
(net NET1
(joined
(portRef 1 (instanceRef R1))
(portRef 3 (instanceRef U1))
)
)
-
Tool-independent standard
Hard to read manually
Heavy for simple use
Tool-Specific Netlists
OrCAD Capture / Allegro
-
More structured than PCB II
Often includes properties, footprints, etc.
Used in professional workflows
Altium / Protel 2+
-
Section-based:
[Components]
R1=10k
[Nets]
NET1=R1-1,U1-3
-
More modern than Protel 1
Less commonly used as interchange vs EDIF
-
KiCad Netlist
-
XML-based (modern versions):
<net name="NET1">
<node ref="R1" pin="1"/>
<node ref="U1" pin="3"/>
</net>
-
Older KiCad also supported:
Pcbnew legacy format
Spice-style exports
-
SPICE Netlist
-
Simulation-focused:
R1 1 2 10k
V1 1 0 DC 5
-
Nodes instead of named nets
No explicit “component blocks”
Very common in simulation
Not ideal for PCB layout directly
-
Other Notable Mentions
Mentor Graphics / PADS
-
Proprietary formats
Often exported to EDIF or OrCAD PCB II
Cadence Allegro
-
Internal formats, usually not used directly for interchange
IPC-D-356
- Netlist for bare board testing
Focuses on connectivity, not components
How your examples fit
| Name you heard |
What it really is |
| Protel1/Tango |
Early Protel / Tango netlist (what TinyCAD exports) |
| OrcadPCB2 |
OrCAD PCB II netlist (very widely supported interchange format) |
Practical reality (what people actually use)
If you’re building tooling (which it looks like you might be 
), the most useful formats to support are:
Most netlists boil down to the same core model:
- Components:
Ref → type/value
Nets: Net → list of (Ref, Pin)
The rest is just syntax.
Well, that shows very well that there exist a huge mess of netlist formats 
- Multiple variants exist
- Sometimes appears as:
- […] legacy […]
- Proprietary formats
- Internal formats
- The rest is just syntax
That is a horrible summary. “The rest is just syntax”, WTF. If our netlist uses a syntax that is “just” a tiny little bit different than what a reader tool expects, the import fails and the whole export is useless. We need a format that is 100% clear and the exporter agrees with all importers on an exact specification.
Anyway, which of those formats would be supported by your mentioned tools?
One has to be careful how to interpret what ChatGPT says, but it does give an idea of what is used, and I think the comment about syntax is making the point that the content is the same.
Quote from my original post:
something like this incomplete Protel example:
[
R6
RESISTOR
50 Ohm
]
[
R7
RESISTOR
50 Ohm
]
(
_net0
R8-1
OP4-1
OP5-1
)
(
_net1
R8-2
D4-2
D3-1
)
I think the name of the net is freeform, so NET0 would do just as well.
I am still skeptical that this will work fine. Anyway, as this format looks quite simple, I made a quick&dirty implementation so we can just try it out. Here are the nightly builds:
In this build, there is a menu item in the File menu to export such a Netlist. I’d appreciate if you can try this out.
I quickly imported it in DIYLC and VeroRoute, but with limited success. Though I have never used those tools before, so I might be doing something wrong.
Great! I gave it a go, but got:
chris@fedora:~$ ./librepcb-nightly-linux-x86_64.AppImage
Incompatible processor. This Qt build requires the following features:
ssse3 sse4.1 sse4.2
Aborted (core dumped) ./librepcb-nightly-linux-x86_64.AppImage
Huh. Is your CPU architecture not x86_64? We only have nightly builds for x86_64 :-/
EDIT: Or does the stable 2.0.1 AppImage work?
EDIT2: Or maybe your CPU is so old that Qt doesn’t support it anymore 
In this case, probably you’d have to build LibrePCB from sources.
AMD Phenom™ II X3 720 × 3
EDIT: Or does the stable 2.0.1 AppImage work?
LibrePCB Version: 2.0.1
Git Revision: 083755c (2026-02-22)
Qt Version: 6.10.2 (built against 6.10.2)
CPU Architecture: x86_64
Operating System: KDE Flatpak runtime
Platform Plugin: xcb
TLS Library: OpenSSL 3.5.5 27 Jan 2026
OCC Library: OCCT 7.9.1
Runtime: Flatpak
EDIT2: Or maybe your CPU is so old that Qt doesn’t support it anymore In this case, probably you’d have to build LibrePCB from sources.
I don't think so :).
DIY Layout Creator works as an AppImage, although I had to:
sudo dnf install fuse-libs
I’ve built RPM, Flatpak and DEB, but have no experience with AppImages, I gave up on them as there didn’t seem to be much support. From my experience of trying to use them (see above), they don’t seem to do what it says on the tin - run from one file on most systems.
Hmm interesting. The CPU is x86_64, but it seems to be pretty old (released in 2008). I guess Qt developers didn’t expect anyone using such an old CPU 
Luckily the Flatpak maintainers seem to be more conservative. I can try to build a Flatpak, just give me a few moments…
AppImages are quite great for “standard” Linux systems. But as soon as you have something “special” (like a very old CPU ), they might not run. In those cases, any package manager works better (apt, Flatpak, Snap, whatever) since they build librepcb from sources.
EDIT: Flatpak built is running, will take some time: build org.librepcb.LibrePCB/test from refs/pull/50/head · flathub-infra/vorarbeiter@78a80ee · GitHub
Nightly flatpak is ready:
flatpak install --user https://dl.flathub.org/build-repo/277905/org.librepcb.LibrePCB.flatpakref
It looks good! It installs, runs and produces a netlist. DIYLC imports the resistors. I’ll look at the file in detail tomorrow.
1 Like
Do the nets also work? When I tried it, I only saw parts imported, but nowhere saw the connections.
Also for me it would be important to know if the pinouts work too. I mean it’s trivial for resistors and capacitors. But what about parts with more pins? Transistors, NPN and PNP? Trimmers? Bridge rectifiers? Relays?
I still wonder how the external tool can know the pinouts. What if they call transistor pins “1”, “2”, “3”, but LibrePCB calls them “B”, “C”, “E”, how does the tool know how to assign the nets?
I used this to test some basic compononents
TESTLibrePCB.zip (86.6 KB)
Only the resistors are imported, I believe the components need to have KiCAD names, these all work and I have reported a bug on the DIYLC forum to ask for a list of valid ones.
CAP_ELECTRO_200_NP
CAP_ELECTRO_NP
DIODE
DIP8
DIP14
LED
RESISTOR
TO92
TO220
I’ve also asked for more information about importing nets. You have a good point about the names of pins which that might help clarify.
The transistors allow editing of the pin format, which probably isn’t much help, but the IC I used as an example just needs pin numbers if that is possible.
That’s exactly what I am trying to explain since the beginning of this thread 
Good I could make it clear now with the test implementation.
So I think you will always need a converter between LibrePCB and DIYLC, with a map of LibrePCB library elements to DIYLC elements. And to make it as reliable as possible, it should operate on UUIDs, not on names. Basically exactly what I proposed in Netlist Export - #19 by ubruhin. Protel netlists are not a great solution.
What I consider to be the other important schematic design software (on Linux at least) can do this (in a couple of cases with the help of my utiity). Your enhancement to Libre PCB already makes the components available, that’s good enough considering that DIYLC doesn’t succeed in importing the nets anyway.
It’s a start.
Hmm but note that the current implementation is just a quick&dirty experiment. It will not land in an official release until it is proven to work with those tools. LibrePCB is a professional-grade software and I have high quality standards, so I’m not shipping half-baked features.
I understand that, you could leave out the nets until we have more information about how it will be handled by DIYLC.
I’ve had a look at VeroRoute and it enables you to add alternative names for components to overcome differences. There’s no sign of the net in there either.
SPICE (if simulation matters)
Key insight