ERC vs DRC: What's the Difference in PCB Design?

Quick answer

ERC (Electrical Rule Check) reasons about the schematic: it compares pin electrical types on each net and flags things like an unpowered input, two outputs tied together, or an unconnected power pin. DRC (Design Rule Check) reasons about the physical board: copper clearance, trace width, via and hole geometry, board-edge spacing, and net-class rules. Neither one proves the board works; a clean report means the design satisfies the encoded rules, not that it is fit for manufacture. A releasable board needs both checks to pass, plus schematic-to-PCB parity between them.

ERC vs DRC at a glance

	ERC	DRC
Runs on	Schematic (symbols, pins, nets)	PCB layout (copper, footprints, layers)
Design stage	Before layout	After placement and routing
Catches	Unpowered pins, conflicting pin types, missing no-connect flags, bad net labels	Clearance violations, narrow traces, annular-ring and via errors, board-edge copper, courtyard overlap
Cannot catch	Wrong resistor value, real-world signal integrity, connector mating orientation	Whether a technically valid net is the correct net; true current capacity without accurate stackup data
Run in KiCad 9	Inspect → Electrical Rules Checker (Schematic Editor)	Inspect → Design Rules Checker (PCB Editor)
Command line	kicad-cli sch erc	kicad-cli pcb drc

ERC checks electrical intent in the schematic

Electrical Rule Check (ERC) reasons about schematic symbols, pins, and nets. A symbol pin has an electrical type—input, output, bidirectional, passive, power input, power output, open collector, and so on. ERC compares the types connected on a net and reports combinations that look impossible or incomplete.

Typical ERC findings include:

• a power-input pin on a net with no declared power source;
• two ordinary outputs connected together;
• an input or power pin left unconnected;
• a no-connect marker attached to a pin that is actually wired;
• inconsistent net labels or hierarchical connections.

ERC does not know whether an I2C pull-up is the right resistance, whether a connector pinout matches its datasheet, or whether 3.3 V is enough current for a radio burst. It checks the intent encoded in symbols. A badly defined custom symbol can therefore make a wrong circuit pass or a correct circuit noisy with false errors.

In KiCad, run Inspect → Electrical Rules Checker in Schematic Editor. Resolve root causes instead of placing No ERC markers until the report is quiet. If a passive power connector legitimately feeds a rail, a PWR_FLAG tells ERC that the net is driven; it does not generate power and should not be used to hide an actually unpowered rail.

DRC checks physical implementation on the PCB

Design Rule Check (DRC) reasons about copper, layers, footprints, holes, board edges, and rules. It evaluates the board’s geometry and connectivity against board setup, net classes, and custom constraints.

Typical DRC findings include:

• copper clearance below the configured minimum;
• a track narrower than its net-class rule;
• an unrouted connection or dangling track;
• annular-ring, via, or drill violations;
• silkscreen over solder-mask openings;
• overlapping courtyards;
• copper too close to the board edge;
• a differential pair violating width, gap, or uncoupled-length rules.

DRC cannot tell that a USB-C footprint is mirrored if its pads follow the schematic netlist consistently. It cannot determine a trace’s true current capacity without accurate stackup, copper, temperature, and rule inputs. A green report means “the board satisfies the encoded rules,” not “the board is fit for manufacture.” The KiCad DRC violation guide explains how to interpret individual report types.

Schematic-to-PCB parity joins the two views

ERC can pass on an updated schematic while DRC passes on an old PCB. The missing step is parity: are the symbols, footprints, pin mappings, and nets used by the board consistent with the schematic?

In KiCad, use Tools → Update PCB from Schematic after accepted schematic changes. Then run DRC with schematic parity enabled. This catches classes of stale-design problems such as a net renamed only in the schematic or a footprint association changed after placement. Read keeping schematic and PCB in sync for a repeatable workflow.

Parity still cannot prove a custom symbol’s pin 4 represents the same physical function as footprint pad 4. That is a datasheet audit.

Run both from the command line

KiCad 9 can produce reports and fail a CI job when violations exist:

mkdir -p build/reports

kicad-cli sch erc \
  --exit-code-violations \
  --output build/reports/erc.rpt \
  hardware/controller.kicad_sch

kicad-cli pcb drc \
  --exit-code-violations \
  --schematic-parity \
  --output build/reports/drc.rpt \
  hardware/controller.kicad_pcb

Run kicad-cli sch erc --help and kicad-cli pcb drc --help on the installed version before copying flags into CI. Pin that KiCad version so the rules engine and report format do not change silently. The command-line ERC guide covers exit codes and automation in more detail.

Keep the generated reports as build artifacts with the design commit. A report without its exact schematic/PCB revision is weak evidence because the files may have changed immediately afterward.

Triage violations without training yourself to ignore them

Use the same sequence for every finding:

1. Locate it and inspect the connected circuit or geometry.
2. Decide whether the design, library data, or rule is wrong.
3. Fix the root cause.
4. If it is an intentional exception, add the narrowest exclusion with a written reason.
5. Rerun the full check.

Do not globally relax a clearance because one connector has fine-pitch pads. Use a footprint- or area-specific rule justified by the fabricator’s capability. Do not mark unused pins with No ERC merely to reduce the count; use explicit no-connect markers when the pin is intentionally unused.

Review exclusions as part of every release. An old exclusion can suppress a new error after a footprint moves or a net changes. Error, warning, and exclusion counts should be visible in the release manifest.

Know what neither check catches

ERC and DRC cannot fully verify:

• manufacturer part number, package variant, or lifecycle;
• connector mating orientation and cable pinout;
• analog stability, RF matching, or antenna performance;
• regulator transients and thermal limits;
• enclosure collisions when models are absent or inaccurate;
• assembly-house process limits not encoded as rules;
• whether the product meets its functional requirements.

Add schematic review, datasheet pin audit, BOM validation, 3D/mechanical review, fabrication-output inspection, and a bring-up test plan. The pre-order DFM checklist picks up where automated design rules stop.

The distinction is simple: ERC checks the logical electrical model; DRC checks the physical board model. A releasable PCB needs both models, parity between them, accurate rules, and human evidence for the properties those models do not represent.

FAQ

What is ERC in PCB design? Electrical Rule Check. It runs on the schematic and flags pin-type conflicts, unpowered nets, and missing no-connect markers before layout starts.

What is DRC in PCB design? Design Rule Check. It runs on the PCB layout and flags copper clearance, trace width, via, and board-edge violations against the fabricator’s rules.

Can DRC pass while the board is still wrong? Yes. A green DRC report means the geometry satisfies the encoded rules, not that the schematic intent, part selection, or connector orientation is correct. Schematic-to-PCB parity and a manual DFM pass are still required.

Do ERC and DRC both need to pass before fabrication? Yes, plus schematic-parity DRC. Passing one without the other leaves either an unvalidated electrical model or an unvalidated physical board.