CSS Specificity Calculator

What this tool does

CSS specificity decides which rule wins when two selectors both target the same element. This calculator parses a selector and breaks it down into the four-part weight the spec actually uses — inline styles, ID selectors, class/attribute/pseudo-class selectors, and element/pseudo-element selectors — then, if you give it a second selector, tells you which one would actually apply.

How to use it

Paste a selector into "Selector A" and you'll get its specificity breakdown immediately. Add a second selector in "Selector B" to compare two competing rules and see a plain verdict on which one wins, including how !important changes the outcome. The tool understands modern selectors too — :not(), :is(), and :has() count the specificity of their most specific argument, while :where() correctly contributes zero, exactly as the CSS spec defines it.

Common use cases

• Figuring out why a style isn't applying even though the selector "looks right"
• Deciding between two ways to write a selector when you want the lower-specificity one for easier overrides later
• Reviewing a pull request and spot-checking whether a new rule will accidentally out-rank an existing one
• Teaching or learning how cascade and specificity actually work, beyond "just add more classes"

Frequently asked questions

How is CSS specificity actually calculated?

It's a four-part score, usually written (a, b, c, d): inline styles count as the highest tier, ID selectors are next, then classes/attribute selectors/pseudo-classes, then element and pseudo-element selectors. Selectors are compared tier by tier, left to right — a single ID always beats any number of classes.

What specificity does :not() have?

None of its own — it takes on the specificity of whatever selector is inside its parentheses. :not(.disabled) counts as one class, the same as .disabled would on its own.

Why does :where() have zero specificity?

It was added specifically so authors could write complex selectors — often for scoping or resets — without adding any specificity weight, making them trivially easy to override later.

Does the order of selectors in my stylesheet matter?

Only as a tiebreaker. If two rules have identical specificity, the one that appears later in the source order wins. If specificity differs, the higher one always wins regardless of order.

Why did adding !important break my override?

!important ignores specificity entirely and wins outright — unless another rule is also marked !important, in which case specificity (and then source order) decides between the two !important rules.