A pin with a "no connection" flag is connected

What this error means

A no-connect flag (the X on a pin) declares "this pin connects to nothing." For every net carrying one, ERC counts the pins on the whole resolved net — including sections joined by labels on other sheets, with a stack of pins at one point counting once. More than one pin means the flagged pin is in the circuit after all, and the declaration is false.

The same violation key fires from a second, flagless path: a pin whose electrical type is Unconnected (set in the symbol editor, not the schematic) with a wire, label, or another pin at its endpoint. The report then reads Pin with 'no connection' type is connected.

ERC stays quiet when the flag sits directly on a hierarchical sheet pin or hierarchical label — the supported way to mark a sheet connection as unused — and when the flag sits on a pin itself typed Unconnected. KiCad 10 widened the sheet-pin case: a no-connect at the end of a wire stub leading only to the sheet pin no longer warns, where KiCad 9 wants the flag exactly on the pin.

Common causes

1. The flag is stale

The pin was marked no-connect in an early revision, then the design grew a wire to it and nobody removed the X. The circuit is right; the annotation is wrong. This is the usual case.

2. The flag was meant to say "optional part"

A no-connect on a wired resistor pad does not mean "this part might be omitted" — it means "this pin touches nothing," and the wire says otherwise. Mark the component DNP instead (symbol properties → Attributes → Do not populate).

3. A label on the flagged stub joins the net elsewhere

A net label merges the stub with every other point carrying that name, so the pin is connected even with no visible wire leaving it. ERC counts pins across the whole named net, not the local stub.

4. Something is wired to a pin of electrical type Unconnected

The Pin with 'no connection' type is connected variant. Library authors type genuinely unusable pins (unbonded pads, reserved pins) as Unconnected; wiring one does nothing electrically — no net forms through the pin, so the far end of that wire can still fail pin_not_connected.

How to fix it

Delete the no-connect flag

Click the X on the flagged pin to select it, then press Delete.
Re-run ERC (Inspect → Electrical Rules Checker).

Use when: The pin is genuinely in the circuit and the flag is left over from an earlier revision. Removing the flag in the checked-in repro drops the warning count to zero.

Disconnect the pin and keep the flag

Hover the pin and press the highlight-net key (backtick) to see everything the net touches, including label-joined sections on other sheets.
Delete the wire, or the label that merges the stub into a larger net, and re-run ERC.

Use when: The pin was supposed to stay unused and the connection is the mistake — often a label typo or a wire dragged one grid step too far.

Stop wiring a pin typed Unconnected — or retype it

If the pin really is unusable, delete the wire; the pin needs no flag.
If the symbol is yours and the pin is functional, open the Symbol Editor, double-click the pin, and set Electrical type to what the datasheet says. Update the symbol in the schematic and re-run ERC.

Use when: The report says `Pin with 'no connection' type is connected`. The problem lives in the symbol's pin definition, not the schematic's flags.

When it’s safe to exclude

Rarely worth it. The warning costs one click to resolve, and a stale X that survives review will mislead someone during bring-up.

The defensible exclusion is a library symbol you cannot edit whose Unconnected-typed pin must be wired anyway (a shared pad). Exclude that marker alone (right-click → Exclude this violation) rather than downgrading the check in Schematic Setup → Electrical Rules → Violation Severity, which also hides every stale flag in the project.

Gotchas

Stacked invisible Unconnected-type pins (a common library idiom) were wrongly flagged by releases between 9.0.1 and 9.0.6 (upstream issue 22409). If a library part suddenly warns on all its NC pins, update KiCad before editing the library.
The marker does not always point at the pin under the X. ERC anchors it to a pin of the offending net — in the repro, the pin at the far end of the wire. Read both @-locations in the report.

Minimal reproduction

Wire two pins together, then put a no-connect flag on one of them: place two resistors, wire pin to pin, press Q with the cursor on one wired pin end to drop the X, and run ERC. The report shows:

[no_connect_connected]: A pin with a “no connection” flag is connected
    ; warning

The checked-in file data/erc/samples/no_connect_connected.kicad_sch reproduces this with two embedded one-pin symbols sharing a wire and a no-connect flag on one endpoint; its two lib_symbol_issues warnings about the missing repro library are an artifact of the self-contained file. Deleting the no_connect element drops the warning (fix #1 in miniature); retyping a pin as Unconnected and wiring it reproduces the Pin with 'no connection' type is connected variant.

Pin not connected
Unconnected "no connection" flag (reference page coming soon)
Pin name resembles stacked pin (reference page coming soon)

FAQ

Why does ERC warn about a no-connect flag on a hierarchical sheet pin?

The sheet pin joins the net to whatever is inside the sheet, so the flagged point reaches other pins. KiCad suppresses the warning when the flag sits exactly on the sheet pin or hierarchical label, and KiCad 10 also tolerates a wire stub between them. On KiCad 9, delete the stub and place the X directly on the sheet pin.

Can I keep the no-connect flag on a wired pin to show the part is optional?

No. The flag means the pin touches nothing, and ERC checks that literally. For a part that may be omitted at assembly, set Do not populate in the symbol's Attributes; connectivity stays intact and ERC stays quiet.

A pin has both a net label and a no-connect flag — why is it 'connected'?

The label merges that pin with every other point in the design carrying the same name, so the pin is connected even when no wire visibly leaves it. Keep the label or the flag, whichever states your actual intent.

Sources

Reviewed against KiCad 9.0.3 on September 9, 2026. Every claim on this page was checked with kicad-cli sch erc.