CSS Specificity Calculator — Score, Compare, and See Why a Selector Wins

Real-world use cases

• Settle a "why isn't my style applying" bug in code review

  A teammate's `#sidebar .link { color: red }` keeps winning over the new `.link--muted { color: gray }` and nobody can say why on sight. Paste both selectors, one per line. The tool scores them (1,1,0) vs (0,1,0) and highlights the ID rule as the winner, with a note that the a column (1 vs 0) decided it. Now the fix is obvious: either raise the muted rule's a column, or — better — wrap the sidebar's `#sidebar` in `:where()` so it drops to (0,1,0) and stops bullying every later override. Two pasted lines end the argument faster than opening dev tools.

• Audit a design system for over-specific defaults

  You're shipping a component library and want every base style to be trivially overridable by consumers. Paste your base selectors in a batch — `.card`, `.card .title`, `#app .card`, `nav ul li a`. Any row scoring above (0,1,0) is a future support ticket: a consumer who can't override it without copying your specificity. Rewrite the heavy ones with `:where()` (e.g. `:where(nav) ul li a` → (0,0,3) instead of (0,0,4) plus structural weight) and re-paste to confirm the triples dropped.

• Decide between :is() and :where() before refactoring

  You're collapsing five near-identical rules into one with `:is()` to cut bytes, but you're not sure if it'll change which declarations win. Paste the original `.menu .a, .menu .b, .menu .c` and the proposed `.menu :is(.a, .b, .c)` and compare the triples side by side — both land at (0,2,0), so the refactor is specificity-neutral and safe to ship. If you'd reached for `:where()` instead, the tool would show the drop to (0,1,0) and warn you the rule just got weaker.

• Teach a junior dev the cascade with a shareable link

  Explaining specificity over Slack is painful. Type a few contrasting selectors, let the URL capture them, and paste the share link. The recipient opens the exact same comparison — `#id` beating `.a.b.c.d.e`, `::before` only adding to the c column, `:where()` zeroing an ID — with the per-token breakdown already rendered. It's a live worked example instead of a wall of theory, and they can edit the selectors to test their own hunches.

• Predict the winner before adding !important

  Before you reach for `!important` to force a style, paste the rule that's currently winning and your new rule. If your new rule's triple is already higher, you don't need `!important` at all — you needed a more specific selector, which the tool will confirm. If they're tied, the tool tells you source order decides, so moving your rule later in the stylesheet fixes it cleanly. Reserve `!important` for the genuine cases where you've confirmed a lower triple can't be raised.

Common pitfalls

• Counting `:where()` as if it added weight. `:where(#nav) .link` is (0,1,0), not (1,1,0) — the entire `:where()` argument contributes zero. If you treat it like `:is()` you'll predict the wrong winner. Read the breakdown chip: the `:where()` token is labelled "always 0".

• Putting `::before` in the b column because it starts with a colon. Pseudo-elements (`::before`, `::after`, `::first-line`) add to c (the element column), not b. Only pseudo-classes (`:hover`, `:nth-child()`) go in b. The double colon is the tell.

• Assuming combinators add weight. `div > p + span` is (0,0,3) — the `>` and `+` count for nothing, only the three element names do. Same for the descendant space and `~`. They affect *what matches*, never *how specific*.

• Treating a big b column as able to overflow into a. Specificity never carries between columns. `.a.b.c…` ×100 is still (0,100,0) and loses to any single `#id` at (1,0,0). There is no base-256 rollover in any current engine.

Privacy