CSS Specificity Calculator

CSS specificity is a scoring system browsers use to decide which CSS rule applies when multiple rules target the same element. It is expressed as three numbers (A, B, C): A counts ID selectors (#id), B counts class selectors (.class), attribute selectors ([attr]), and pseudo-classes (:hover), and C counts element selectors (div) and pseudo-elements (::before). Higher numbers win, compared left to right.

When two selectors have equal specificity, the one that appears later in the stylesheet wins (source order). However, specificity always takes priority over source order — a more specific selector will win even if it appears earlier in the CSS file.

!important overrides all specificity calculations. However, if two rules both use !important, normal specificity comparison applies between them. Overusing !important leads to unmaintainable CSS — it is better to increase specificity intentionally or restructure your selectors.

The :not(), :is(), and :has() pseudo-classes themselves add zero specificity. Instead, they take the specificity of their most specific argument. For example, :not(.active) has the same specificity as .active → (0,1,0). The :where() pseudo-class is unique — it always has zero specificity regardless of its arguments.

Inline styles (style="...") have a specificity that beats any selector-based rule. The only way to override an inline style with a stylesheet rule is to use !important. In specificity notation, inline styles are sometimes represented as (1,0,0,0) — a fourth component that outranks all selector specificity.

The goal is FLAT specificity — most rules at roughly the same low weight — so the cascade is decided by source order, which is predictable, instead of by escalating selectors. Practical tactics: prefer a single class per rule (.card-title, not header.main .card h2); avoid IDs for styling (an ID jumps you to a high column you'll have to out-specify forever); wrap selectors in :where() when you want them to match but contribute ZERO specificity, which is great for resets and defaults that should be easy to override; and lean on a methodology like BEM that names components with classes. When you find yourself reaching for !important to win, that's the signal your specificity is already too tangled — flatten the selectors instead. !important should be a last resort (or reserved for utility overrides), not a routine tool.

@layer lets you group CSS into ordered layers, and the layer order beats specificity entirely between layers. You declare an order — @layer reset, base, components, utilities — and a rule in a LATER layer wins over a rule in an earlier layer even if the earlier rule has higher specificity. This is transformative for managing large codebases and third-party CSS: you can put a framework in a low-priority layer and your overrides in a higher one, so your simple .button class reliably beats the framework's .nav ul li a without a specificity arms race. Within a single layer, normal specificity and source order still apply. Cascade layers are supported in all current major browsers and are the modern way to make 'which rule wins' intentional rather than accidental.