CSS Specificity Calculator

Why specificity decides which CSS wins

When two CSS rules target the same element and set the same property, the browser needs a tie-breaker. That tie-breaker is specificity — a score the browser computes for each selector. The rule with the higher score wins, no matter where it sits in the file. This is why your carefully written .button { color: blue } sometimes refuses to override a stubborn earlier rule, and why some developers reach for !important out of frustration. Understanding specificity turns those mysteries into arithmetic. This calculator parses any selector and shows you its exact score, the reasoning behind it, and which of two selectors would win.

The three-number score (A, B, C)

Specificity is not a single number but a triplet, written here as (A, B, C), compared left to right like version numbers. Each component counts a different kind of selector:

The universal selector * and combinators (>, +, ~, and the descendant space) add nothing to the score. A single ID always beats any number of classes, and a single class always beats any number of element types — the columns never "carry over." That is the crucial insight: ten classes (0, 10, 0) still lose to one ID (1, 0, 0).

How this tool reads a selector

Paste a selector and the calculator tokenizes it, classifying every piece into the A, B, or C bucket and color-coding it: red badges for IDs, blue for classes and pseudo-classes, green for types and pseudo-elements, gray for the no-weight universal selector. It then sums each column and displays the final triplet. The token breakdown is what makes it a learning tool rather than a black box — you see why the number came out the way it did. There's also a Compare tab that pits two selectors against each other and declares the winner, and an Examples tab with a dozen reference selectors you can click to inspect.

A worked example

Take #nav ul > li.active a. The calculator breaks it down like this: #nav is one ID (A=1); .active is one class (B=1); and ul, li, and a are three type selectors (C=3). The > combinator and the descendant spaces contribute nothing. The final score is (1, 1, 3). Now compare it with .menu .active a, which scores (0, 2, 1): two classes and one type. Even though the second selector has more classes, the first wins instantly because it has an ID and A is compared first — 1 beats 0 before B or C is even considered.

Practical use cases

• Debugging "why isn't my style applying?" Compare your selector against the one currently winning in dev tools to see exactly how far short you fall.
• Code review. Spot overly specific selectors (lots of IDs and chained classes) that will be painful to override later.
• Teaching and learning. The colored token breakdown makes an abstract rule concrete for anyone new to CSS.
• Planning a refactor. Before flattening a stylesheet, check which rules carry the most weight so you don't accidentally change the cascade.

Tips and common mistakes

• When scores tie, source order decides. Two selectors with identical specificity? The one written later in the stylesheet wins. The Compare tab calls this out explicitly.
• Inline styles outrank selectors. A style="..." attribute on the element beats any selector in a stylesheet. It sits above the (A, B, C) scale entirely.
• Avoid the !important trap. Adding !important overrides specificity, but it's a blunt instrument — once you use it, the only way to override that is another !important, and you've started an arms race. Reach for a more specific selector first.
• Lower specificity is usually better. Counter-intuitively, you want selectors that are easy to override. Favor single classes over long ID-laden chains so your styles stay maintainable.
• Functional pseudo-classes are special in real CSS. In a full browser, :not() and :is() take the specificity of their most specific argument, while :where() always contributes zero. This calculator approximates these as a simple class-level weight, so treat its result for those as a close estimate rather than the final word.