CSS specificity calculator

What is CSS specificity?

When two CSS rules both apply to an element and set the same property, specificity decides which one wins. It is worked out from the selector alone — not from where the rule sits, not from how complicated it looks — and the CSS Selectors specification defines it as three counts rather than one number.

The first, A, is the number of id selectors. The second, B, counts class selectors, attribute selectors and pseudo-classes together — an attribute selector really does weigh exactly the same as a class. The third, C, counts type selectors and pseudo-elements. The universal selector counts for nothing at all.

Paste a selector above and you get those three numbers, plus a line for every part explaining which column it landed in and why. Put a second selector in and it tells you which of the two would win.

How to use it

1. Type or paste a selector. Anything from div to #nav .item:not(.disabled)::before. Selector lists separated by commas work too, and each entry is counted on its own.
2. Read the working, not just the total. Every simple selector gets its own line saying which column it counted in and why, so a surprising total is explained rather than asserted.
3. Add a second selector to compare. You get the winner, and the base-10 score beside it — with a warning on the occasions when that shortcut points the wrong way.

Why eleven classes do not beat an id

Almost everyone learns specificity as arithmetic: an id is worth 100, a class 10, an element 1, add them up and the bigger number wins. It is a useful lie that works for nearly every selector anyone writes, and then stops working without warning.

The specification is explicit that the three numbers are compared one column at a time: the larger A wins outright, and only if the A values tie does B get looked at, and only then C. There is no carrying, no total, and no exchange rate. One id beats any number of classes — a hundred of them, a thousand.

Eleven is where the shortcut starts lying, and that is not a guess. Eleven classes score 110 against an id's 100, so the arithmetic says the classes win while the cascade says the id does. Ten classes still score 100, a tie the shortcut resolves the same way the real rule does by accident. The tool ships with exactly that pair loaded so you can see the two models disagree rather than take it on trust.

This is not a hypothetical either. A utility-first stylesheet stacks classes on a single element as a matter of course, and the specification notes that repeating a simple selector really does increase specificity — .btn.btn.btn is 0-3-0. Eleven is closer than it sounds.

The parts that catch people out

Four pseudo-classes have their own rules, and they are where hand-calculations go wrong. :is(), :not() and :has() do not count themselves at all — each takes the specificity of the most specific selector inside it, so :not(#a) is worth a whole id. :where() is the opposite and is the useful one: it is replaced by zero, so everything inside contributes nothing however specific it looks, which is what makes it the right tool for default styles you want to be easy to override.

:nth-child() and :nth-last-child() are the obscure pair. They count as one pseudo-class for themselves, and then add the most specific selector in an of clause if there is one — so :nth-child(2n of .item) is 0-2-0, not 0-1-0.

Then there is a trap of pure history. :before, :after, :first-line and :first-letter are pseudo-elements written with a single colon, allowed for compatibility with CSS2. The single colon makes them look like pseudo-classes, and they are counted in the third column with type selectors regardless. Every other single-colon name is a genuine pseudo-class and counts in the second.

Honest limits

Specificity is only one step of the cascade, and this page calculates that step alone. Before it comes origin and importance — an !important declaration in a stylesheet beats a normal one whatever the selectors say, and cascade layers are considered before specificity too. Inline styles sit outside the selector tuple entirely, and there is no selector you can write that outranks one. After specificity, if two rules are still tied, the later one in source order wins, which is what the tie result here means.

The calculation also assumes a valid selector. This reads what you type without checking that a browser would accept it, so a typo will be counted rather than rejected, and vendor-prefixed or newly-proposed pseudo-classes are treated as ordinary ones unless they are among the special cases above.

One more thing worth knowing: the specification permits implementations to clamp the three values if they run out of storage, so an absurd selector may be capped in a real browser rather than counted exactly. Nothing you would write by hand comes close.

The numbers here were checked against the specification's own fourteen worked examples, and separately against a reference implementation over 980 generated selectors with no disagreements.

Why is it free?

Because it costs nothing to run. The parsing and counting happen in your browser; no selector is uploaded, no server sees your stylesheet, and there is no account.

The rules come from the CSS Selectors specification rather than from a tutorial, and the tests that check them are committed alongside the code — including the spec's own examples, which is a stronger standard than agreeing with another calculator.