Before you route a single trace, KiCad can tell you whether your schematic actually makes electrical sense. That's the job of ERC.
Short answer: ERC (Electrical Rules Check) analyzes your schematic's electrical connectivity and intent — checking that pins are connected the way their types imply, that every power net has a source, and that nothing is wired in a way that contradicts itself. It runs on the schematic, not the PCB, so it catches design mistakes early, before they turn into a scrapped board.
What ERC actually checks
ERC doesn't simulate your circuit or verify that your design is correct in an engineering sense. It checks consistency: does the way you've wired things match the electrical types you (and the symbol libraries) declared?
Every pin in a KiCad symbol has an electrical type — input, output, bidirectional, power input, power output, passive, open collector, and so on. ERC walks every net and asks whether the combination of pin types on that net is legal. It also looks for structural problems: pins connected to nothing, wires that dangle, labels that never join another label, and buses that don't match.
A clean ERC report doesn't guarantee a working board — but a schematic full of ERC violations almost always hides real bugs.
Warnings vs errors — and why not every warning is a bug
KiCad classifies each violation as an error or a warning, and you can change the severity of most rules in Schematic Setup → Electrical Rules → Severity.
- Errors are things KiCad considers very likely wrong: an unconnected pin, two outputs shorted together, a power input with no source.
- Warnings are things that are often wrong but sometimes intentional: a passive symbol with an unusual connection, a label used only once, a pin type combination that's unusual but not illegal.
The important mindset: a warning is a question, not a verdict. Some warnings describe exactly what you intended — a test point tied to one net, a mounting hole left floating on purpose. Review each one, fix the genuine issues, and deliberately suppress the rest (right-click the marker → Exclude this violation, or lower its severity). Once you've done that, a clean report becomes meaningful: it means nothing new has slipped in.
The most common ERC issues and how to fix them
Most ERC reports are dominated by a handful of recurring issues. Here's what they mean and how to clear them.
| Issue | What it means | How to fix |
|---|---|---|
| Pin not connected | A pin touches no wire, label, or junction | Wire it up, or add a no-connect flag if it's genuinely unused |
| Input power pin not driven by any power output | A power input net has no declared source | Add a PWR_FLAG to the net (see below) |
| Conflict: output connected to another output | Two output pins drive the same net | Rewire so only one driver owns the net, or change a pin type if a symbol is mislabeled |
| Unconnected wire end / dangling wire | A wire segment ends in open space | Delete the stub or connect it to its intended pin |
| Pin not driven by any output | An input expects a driver but sees none | Connect it to the correct signal source |
| Pin type conflict | Two incompatible pin types share a net (e.g. output vs power output) | Correct the wiring, or fix the symbol's pin electrical type |
| Label not connected | A net label appears only once | Connect the second endpoint, or remove the stray label |
Unconnected pins
The most frequent violation. KiCad flags any pin that isn't joined to a wire, junction, or label. Usually it's a missed connection — zoom in, and you'll often find a wire that looks attached but stops a grid step short. Fix it by completing the wire. If the pin is meant to be unused, use a no-connect flag instead (next section).
No-connect flags for intentionally unused pins
Many parts have pins you legitimately don't use — spare gates, NC pins, unused GPIO. Marking every one as an error would bury the real problems. Place a no-connect flag (the little X, shortcut Q, or Place → No Connection Flag) directly on the pin. This tells ERC "this is unconnected on purpose," and the unconnected-pin error for that pin disappears — while any pin you forgot still gets flagged.
"Input power pin not driven by a power output" and the PWR_FLAG fix
This is the ERC message that confuses newcomers most, and it deserves a clear explanation.
KiCad treats power input pins specially. A pin typed power input (the VCC, GND, VDD pins on nearly every IC) expects to be fed by something typed power output. KiCad's power symbols like +3V3 and GND are only labels — they mark the net name but do not count as a source. So when your 3.3 V rail is fed by a connector pin, a battery terminal, or a regulator output that KiCad sees as passive rather than power output, ERC concludes the net has no real source and warns that the power input pins aren't driven.
PWR_FLAG is the fix. It's a special symbol (in the power library) whose single pin is typed power output. You place it on the net to tell ERC, in effect, "power really does enter the circuit here." It changes nothing electrically — it's purely an annotation of intent for the rules checker.
Where to place it: on nets where power originates but no symbol declares itself a power output — typically a regulator output, the incoming rail from a power connector, and very commonly your GND net (a ground symbol is just a label). Add PWR_FLAG, re-run ERC, and the "not driven by a power output" warnings clear.
Conflicting outputs (output–output)
If two pins typed output land on the same net, ERC flags a conflict — in real hardware, two drivers fighting over one wire can damage parts. Either the wiring is wrong (fix the net), or one symbol's pin is mislabeled and should be bidirectional, open-collector, or tri-state. Correct the pin's electrical type in the symbol if the symbol is at fault.
Symbol pin type mismatches
Because ERC leans entirely on pin electrical types, a wrong type in a custom or third-party symbol produces phantom violations no amount of rewiring will clear. If a marker insists a correctly-wired net is wrong, open the symbol in the Symbol Editor and check that each pin's electrical type reflects reality.
How to run ERC in the GUI
In the schematic editor, open Inspect → Electrical Rules Checker, then click Run ERC. Violations appear as a list and as markers placed right on the schematic, so you can click a violation and jump to the offending pin or wire. Right-click any marker to exclude it or change its severity. Work the list until only intentional exclusions remain.
How to run ERC from the command line
For automation, KiCad ships kicad-cli, which runs ERC headlessly and writes a machine-readable report — no GUI required:
kicad-cli sch erc --output erc.json --format json --exit-code-violations board.kicad_sch
The --format json flag produces structured output you can parse, and --exit-code-violations makes the command return a non-zero exit code when violations are found — perfect for failing a check automatically when a schematic regresses.
Make ERC run itself on every change
Running ERC by hand works, but it only helps when you remember to do it. The mistakes that reach a fab are usually the ones caught right before deadline — or not at all.
That's exactly what GoForFab automates. Connect your KiCad project and every push runs the full checks — ERC included — so schematic mistakes surface the moment you introduce them, not the night before you order boards. It's free forever on the base tier, and the report sits alongside your Gerbers, BOM, and 3D renders. If you also want to tighten up your layout checks, our guide to fixing common KiCad DRC errors covers the PCB side of the same discipline.