How CSS Specificity Is Calculated
Specificity is a three-part weight, conventionally written (a, b, c): a counts ID selectors (#header), b counts classes, attribute selectors, and pseudo-classes (.btn, [type="text"], :hover), and c counts element type selectors and pseudo-elements (div, ::before). A selector with a higher a always beats one with a lower a, regardless of b or c, so #a beats .b.c.d.e.f no matter how many classes pile up. Within the same a, the same comparison applies to b, then c. This tool also reports a single combined score (a×10000 + b×100 + c) purely to make sorting and comparing selectors at a glance easier; the actual CSS cascade always compares a, b, c as separate tiers, never as one merged number.
How :is(), :where(), :not(), and :has() Affect Specificity
The CSS Selectors Level 4 spec gives these functional pseudo-classes special rules. :is(), :not(), and :has() each take on the specificity of their single most specific comma-separated argument, not the sum of all of them: :is(#foo, .bar) scores the same as #foo alone (a=1), because #foo is more specific than .bar, and the lower-specificity argument doesn't add anything on top. :where() is the exception: it always contributes zero specificity, no matter what's inside it, which makes it useful for writing default styles that are trivially easy to override. Nesting works too, so :not(:is(a, b)) is evaluated as :not() taking the max specificity of a and b's own specificity.
Comparing Multiple Selectors to Debug Cascade Conflicts
Paste several selectors, one per line or comma-separated, to see them all scored and sorted with the highest-specificity one flagged. This is the fastest way to answer "why isn't my CSS rule applying": if two rules target the same element and one isn't taking effect, compare their specificity here rather than guessing from the source order alone. The rule with the higher (a, b, c) wins regardless of where it appears in the stylesheet; only when two selectors have exactly equal specificity does the later one in source order win.
Common Specificity Pitfalls
Inline styles (style="...") and !important both sit outside the normal (a, b, c) system entirely: inline styles win over any selector-based rule (short of !important), and !important overrides everything else regardless of specificity, including other !important rules with lower specificity. Legacy single-colon pseudo-elements like :before and :after are treated identically to their modern double-colon form (::before, ::after) here, both counted as element-level (c), even though older code still writes them with one colon. The universal selector (*) and combinators (>, +, ~, and the descendant space) add zero specificity of their own; only the compound selectors on either side of a combinator contribute weight.
Specificity vs. Source Order
Specificity and source order solve the same problem, which rule wins, in different ways, and understanding when each one applies is essential for predictable CSS. When two rules have different specificity, the higher one always wins, no matter which comes first or last in the stylesheet. When two rules have exactly equal specificity (the same a, b, c triple), the cascade falls back to source order: whichever rule appears later in the CSS (or is loaded later) wins. This is why two selectors that look very different, like .card .title and .header .name, can still tie: both are one class plus one class, giving identical (0, 2, 0) specificity. As a specificity calculator online, this doubles as a css cascade calculator for css selector weight, an is specificity calculator and where specificity checker, reporting a css specificity score that shows which css selector wins, making it a css selector priority calculator for debugging real stylesheets.