KiCad net classes and design rules: a practical setup guide

Net classes are how you tell KiCad that different signals need different physical rules — and then let the Design Rules Checker enforce them for you. Set them up once and your power traces stay fat, your USB pair stays tight, and DRC flags anything that drifts out of spec before it reaches a fab.

Short answer: In KiCad, open Board Setup → Design Rules → Net Classes, define a class per signal type (Default, Power, High-speed), give each its clearance, track width, and via sizes, then assign nets to those classes. DRC reads those constraints on every check. Keep every value at or above what your fab can actually build.

What net classes are and why they matter#

A net class is a named bundle of nets that share the same rules: minimum clearance, track width, and via dimensions. Instead of setting the width of every power trace by hand, you put all the power nets in a Power class, define the rules once, and every track on those nets inherits them.

That matters for two reasons. First, consistency — a 5 V rail routed at 0.25 mm in one corner and 0.6 mm in another is a current-carrying gamble. A class makes the whole rail obey one width. Second, enforcement — because the rules live in a class, the Design Rules Checker can compare every track and via against them and tell you exactly where you broke your own spec.

Every board starts with one class, Default, that every net belongs to until you say otherwise. You add classes on top for the nets that need something different.

Setting clearances, track widths, and via sizes in Board Setup#

Open File → Board Setup, then Design Rules → Net Classes. Each row is a class, and the columns are its constraints:

• Clearance — the minimum copper-to-copper gap for nets in this class.
• Track Width — the default (and minimum) trace width applied when you route these nets.
• Via Size / Via Hole — the pad diameter and drill for vias placed on these nets.
• Diff Pair Width / Gap — for classes carrying differential pairs, the trace width and the spacing between the two lines.

Here is an illustrative starting point. These numbers are examples only — your current requirements and your fab's process define the real values.

Notice the Default class doubles as your floor: because every net is a member until reassigned, its clearance and width are effectively the tightest rules your board will tolerate unless a stricter class overrides them. Set Default to something safely manufacturable and treat the other classes as deliberate exceptions.

The separate Constraints page in Board Setup sets absolute board-wide minimums (minimum track width, minimum via, minimum hole, minimum annular ring). Those are the hard floor DRC will never let you cross; net classes are the per-signal rules layered on top.

Assigning nets to classes#

Defining a class does nothing until nets belong to it. KiCad gives you two ways:

By pattern, in Board Setup. In the same Net Classes dialog there's an assignment table where you match nets to classes with patterns. A pattern like /VBUS or +5V or VCC* sweeps every matching net into the Power class in one line — the fastest approach when your nets are named consistently.

By net name, in the schematic. You can also tag nets with a net class directive in the schematic editor, which keeps the intent next to the design. This is handy for a specific pair like a USB D+/D- that you want in a HS class regardless of naming.

A practical convention: name your classes after intent — POWER, USB, HS — and lean on patterns so that adding a new rail later automatically lands in the right class. For example, assign everything matching +*V and GND to POWER, USB_* to USB, and leave everything else on Default.

How net classes feed DRC#

This is where the setup pays off. When you run Inspect → Design Rules Checker, KiCad walks every track, pad, via, and gap and compares it to the constraints of the class each net belongs to. A Power net routed at 0.25 mm when its class demands 0.60 mm is a violation. A HS pair whose gap drifts is a violation. A via smaller than the class minimum is a violation.

The result is that your net classes become an automated contract: you state the physical rules once, and DRC guarantees the copper matches them. That's far more reliable than eyeballing trace widths. If DRC is throwing errors you don't understand, our guide to fixing common KiCad DRC errors walks through what each one means. And when the built-in class constraints aren't expressive enough — say you need "this net must be 0.3 mm from that net specifically" — KiCad's custom design rules let you write those conditions by hand.

Matching your fab's capabilities to your rules#

Net classes only protect you if their numbers reflect reality. Every fab publishes a capabilities sheet: minimum trace width, minimum trace spacing, minimum drill, minimum annular ring. Your Default class clearance and width must sit at or above those minimums, or DRC will happily pass a board the fab physically cannot make.

The workflow: pull your fab's specs, set the Board Setup Constraints page to their hard minimums, then set each net class no tighter than that. For controlled-impedance signals the width isn't a free choice at all — it's dictated by your stackup, and you calculate it rather than guess. Our guide to controlled impedance in KiCad covers how to derive those trace widths from your layer stack.

Run DRC on your rules automatically#

Setting up net classes is a one-time job; keeping them honest is the ongoing one. It's easy to define perfect rules, then quietly introduce a too-thin power trace three commits later and never notice until the fab rejects the order.

That's the gap GoForFab closes. Connect your KiCad project and every push re-runs DRC against your net classes and constraints, so a rule violation shows up the moment it's introduced — not after you've paid for boards. It uses kicad-cli under the hood, the same engine as your desktop DRC, so the results match what you see locally. It's free forever, and it turns "I hope I didn't break a clearance" into a check that runs on its own.

Define your classes deliberately, keep them within your fab's limits, and let DRC — locally and on every push — do the enforcing. That's the whole point of net classes: you decide the rules once, and the tools make sure the copper obeys.