CSS Specificity Calculator
Calculate and compare the specificity of CSS selectors
!important on a selector above to see it override specificity entirely — any !important rule beats every non-important one regardless of specificity, with specificity only breaking ties among multiple !important rules. Inline style="" attributes aren't represented here. :where() always contributes zero; :not(), :is(), and :has() contribute the specificity of their most specific argument.About this tool
The CSS Specificity Calculator computes the specificity of any CSS selector — how strongly it overrides other rules targeting the same element — and shows it as the standard (IDs, classes/attributes/pseudo-classes, elements/pseudo-elements) triple. Enter two or more selectors, one per line, and it highlights which one wins when both target the same element. Specificity is the single most common source of "why isn't my CSS applying" confusion — a rule can be correct and still lose to another rule that's simply more specific, regardless of source order. This tool also correctly handles the selectors people usually get wrong by hand: `:where()` always contributes zero to specificity (that's its entire purpose — grouping selectors without affecting the cascade), while `:not()`, `:is()`, and `:has()` contribute the specificity of whichever argument inside them is most specific, not the specificity of the pseudo-class itself.
When to use it
- →Debugging why a CSS rule isn't applying even though it appears later in the stylesheet
- →Deciding between adding a class vs. relying on element/descendant selectors when writing new CSS
- →Understanding the specificity cost of using :not(), :is(), or :where() in a selector before shipping it
- →Reviewing a CSS-in-JS or utility-class refactor to confirm specificity didn't quietly change
Tips
- ◆Specificity is compared left to right as separate counts, not added into one number — a single ID (1,0,0) always beats any number of classes (0,99,0), no matter how many classes are stacked.
- ◆Toggle !important on a selector to see it override specificity entirely — a single !important selector beats every non-important one regardless of how low its own specificity is.
- ◆Inline style="" attributes aren't part of this comparison — they're not a selector at all, and in practice beat every selector-based rule except an !important one.
- ◆Use :where() specifically when you want to group selectors for convenience without adding any specificity weight — it's the one selector in CSS designed to be "invisible" to the cascade.
Frequently asked questions
Why does :not(.foo) count as one class of specificity but :where(.foo) counts as zero?
:not() takes on the specificity of its argument (here, one class) — it's a normal pseudo-class that just negates a condition. :where() is specifically defined by the CSS spec to always contribute zero specificity regardless of what's inside it, which is exactly why it exists: to let you group or reset selectors without accidentally out-specifying other rules.
What happens with :is(#foo, .bar) — does it count both the ID and the class?
No — :is() (and :has()) take on only the specificity of their single most specific argument, not the sum of all arguments. :is(#foo, .bar) has the specificity of #foo alone (one ID), because #foo is more specific than .bar; .bar's specificity is simply discarded for this calculation.
Does source order matter if two selectors have identical specificity?
Yes — when two rules have exactly equal specificity, the one that appears later in the stylesheet (or later in a later-loaded stylesheet) wins. Specificity only decides the winner when the values actually differ; a tie is broken by cascade order.