Circuitscript vs KiCad Schematic

If you are evaluating code-based schematic tools, you almost certainly already use KiCad. It is the default for open-source hardware, and its schematic editor is mature, well-supported, and free. Both the KiCad schematic editor and Circuitscript produce what pcbnew needs for layout, so the only step in question is schematic authoring, and the useful comparison is narrow: a mature GUI with deep libraries, or a plain-text source that reads cleanly in a pull request. Whether that swap is worth it depends on what you need from that one step.

What KiCad Schematic does well

KiCad has been developed for over two decades and is used in professional hardware development worldwide.

KiCad's component library ships with thousands of symbols and footprints, actively extended by the community. For most standard parts, the symbol and footprint already exist and are ready to drop in. Circuitscript has a catalog that is ported from the KiCad symbol libraries (circuitscript/kicad-libraries), but KiCad's access is native and comes with the full symbol editor.

The schematic-to-layout link is the other capability a netlist handoff cannot match. Net assignment, footprint association, and the update-from-schematic workflow have been refined over years of use. Circuitscript hands off to pcbnew through a netlist while KiCad's schematic editor is already inside the same suite.

That maturity means that .kicad_sch files are understood by contract manufacturers, EMS providers, and design-review teams, so sharing a project with an outside reviewer or manufacturer is common. And if your team already has a KiCad library, a set of approved footprints, and a review process built around the toolchain, switching schematic tools carries an adoption cost.

Side-by-side: what a change looks like in git

Both tools ultimately feed the same pcbnew layout. The difference shows up the moment you put the schematic under version control and try to review a change. Say you add a decoupling capacitor to a supply rail.

KiCad (.kicad_sch):

+  (symbol (lib_id "Device:C") (at 132.08 88.9 0) (unit 1)
+    (in_bom yes) (on_board yes) (uuid 8f2a1c94-...)
+    (property "Reference" "C3" (at 134.62 87.63 0) ...)
+    (property "Value" "100nF" (at 134.62 90.17 0) ...)
+    (pin "1" (uuid 3b7e...)) (pin "2" (uuid a1d0...)))
+  (wire (pts (xy 132.08 85.09) (xy 132.08 83.82)) ...)
+  (junction (at 132.08 83.82) (diameter 0) ...)

Circuitscript (.cst):

   at v3v3
+  wire down 100
+  add cap(100n)
+  wire down 100
+  to gnd

Both add the same capacitor. The KiCad diff is a bunch of UUIDs and coordinate attributes; a reviewer cannot tell what changed electrically without opening the schematic tool. The Circuitscript diff is a handful of lines a human can read in a pull request. at v3v3 puts you on the supply, add cap(100n) places the part, and the wire/to gnd commands route it to ground. The concepts (cursor position, net membership, component placement) are language primitives, and the diff reflects them.

What Circuitscript does differently

Plain text, diffable in git

A .cst file is a readable description of your circuit, so git diff produces output a human can parse — the difference the example above shows, and it holds for every change, not just adding a part.

Code reuse and parameterization

Functions and modules let you define a sub-circuit once and instantiate it many times. A USB-C power-delivery block, a standard RC filter, a common sensor breakout: write it once, parameterize it, reuse it across designs. Resistor values, supply voltages, and component counts can be variables or function arguments, so swapping a value or changing a quantity is a one-line edit rather than a manual search across a canvas. KiCad has hierarchical sheets, but nothing as direct as passing an argument to a parameterized block.

Refdes changes are readable in a diff

KiCad also keeps refdes stable across edits — that's what annotation and "keep existing annotations" are for. The difference is what you see when a refdes actually changes. In .kicad_sch, a reannotation touches UUID-linked properties buried in an s-expression tree; the diff doesn't read as "C3 became C4," it reads as a block of unrelated-looking attribute churn, and confirming what happened means reopening the schematic. Circuitscript's -u flag writes locked refdes into the .cst file as plain comments next to the part they belong to, so a reannotation shows up as a one-line comment change on the part in question — readable in the pull request itself, no tool required. It also holds up through reuse: instantiate the same parameterized sub-circuit multiple times and each instance gets unique, stable references without a manual re-annotate pass.

Layout is a command away, not a re-draw

The wire and at commands describe spatial arrangement as well as connectivity, so the source you diff in git is also what produces the rendered schematic. KiCad gives you the same placement control, but that layout lives in the GUI session — reproducing it means opening the tool. Here, regenerating the SVG, PDF, and netlist from source is one command each, always consistent with whatever the .cst file currently says:

circuitscript input.cst output.svg
circuitscript input.cst output.pdf
circuitscript input.cst output.net

Same source, three outputs, always in sync. The schematic reads the way you laid it out rather than the way an auto-placer arranged it.

Bench editor

bench.circuitscript.net runs Circuitscript in the browser with no installation. Paste a circuit, watch the schematic render live, and export when you are ready. It is the fastest way to try the authoring experience before committing to an install.

How they work together

For a KiCad user, this is the part that matters most. Circuitscript exports a KiCad netlist directly:

circuitscript input.cst output.net

That .net file imports into pcbnew for layout the same way any other netlist does. The footprints come from the params defined on your components in the Circuitscript source, so every component needs a footprint assigned for the export to work.

The first PCB designed with Circuitscript went through exactly this path: a CH340 USB-UART bridge, written in .cst, exported as a KiCad netlist, imported into pcbnew for layout, and manufactured through JLCPCB. See this writeup for more details.

The workflow looks like this:

1. Author the schematic in Circuitscript (.cst)
2. Run circuitscript -u my_board.cst to lock in refdes assignments
3. Export the KiCad netlist: circuitscript my_board.cst my_board.net
4. Import into pcbnew, complete the layout
5. Generate gerbers and submit for fabrication

Steps 4 and 5 are identical to a standard KiCad workflow. Circuitscript replaces only the schematic authoring step, and it connects directly to the next one.

Key differences at a glance

	KiCad Schematic	Circuitscript
Authoring model	GUI canvas	Purpose-built DSL (text)
Schematic source	.kicad_sch (UUIDs, coordinates)	.cst (human-readable)
Meaningful git diffs	No	Yes
Code reuse / parameterization	Hierarchical sheets	Functions, modules, arguments
Refdes reannotation shows in diff as	UUID/attribute churn	One-line comment change
Component library depth	Massive, native	Ported KiCad library
PCB layout	Yes (pcbnew)	No (exports netlist to pcbnew)
KiCad netlist export	Native	Yes
Graphical output	GUI-rendered	SVG, PDF from source
Online editor	No	Yes (Bench)
Maturity	Since 1992	Since 2025
Community size	Very large	Smaller
License	GPL	MIT

When KiCad Schematic is the better fit

• You need a massive out-of-the-box component library with symbols and footprints already defined
• Your team already has KiCad library standards, approved footprints, and a review process built on the toolchain
• You are sharing designs with a contract manufacturer or EMS provider in a format they already accept
• Your schematics are small, stable, and reviewed infrequently, so diffable source buys you little
• You want schematic authoring and PCB layout in one integrated suite

When Circuitscript is the better fit

• You want schematic changes to be reviewable in git like code, not an opaque block of coordinate deltas
• Your design has repeated sub-circuits or parameterized values you would rather express once and reuse
• You want a diffable, version-controlled schematic source that survives component reordering with stable refdes
• You want both a deliberately arranged graphical output and a KiCad netlist from one source file

Both end up in the same place

The two tools converge on the same layout step, so this is not an either/or about your whole toolchain, only about how you author the schematic. If your current pain point is that schematic changes are unreviewable in a pull request, or that repeated sub-circuits mean repeated manual work, Circuitscript addresses exactly that while still handing off to pcbnew. If your schematics are small and stable and your team lives in KiCad, there is no reason to change.

---

Try Circuitscript in the browser at bench.circuitscript.net, or install the CLI:

npm install -g circuitscript