How does CSS selector specificity work?

CSS specificity is the algorithm browsers use to decide which CSS rule wins when multiple rules target the same element. It's a scoring system — the more specific a selector is, the higher its score, and the higher-scoring rule takes precedence regardless of source order.

Specificity is calculated as a tuple of four categories, often written as (a, b, c, d). Each category outranks all lower categories combined — a single ID selector beats any number of class selectors.

To calculate specificity, count how many of each category appear in the selector. The following examples show how different selectors score. Notice how a single ID outranks multiple classes, and how combining selectors adds up their individual contributions.

/* (0, 0, 0, 1) — one element */
p { color: black; }

/* (0, 0, 1, 0) — one class */
.text { color: blue; }

/* (0, 0, 1, 1) — one class + one element */
p.text { color: green; }

/* (0, 0, 2, 1) — two classes + one element */
div.card.active { color: purple; }

/* (0, 1, 0, 0) — one ID (beats ALL class combinations) */
#header { color: red; }

/* (0, 1, 1, 1) — one ID + one class + one element */
#header .nav a { color: orange; }

/* (0, 2, 0, 0) — two IDs */
#page #header { color: crimson; }

The key insight is that categories never overflow into each other. Even 100 class selectors cannot beat a single ID selector. Each column is compared independently from left to right.

Here's a common scenario that trips people up. Three rules target the same button, but they have different specificities. Even though the last rule appears later in the stylesheet (which normally wins in a tie), specificity takes precedence over source order.

/* Rule 1: (0, 1, 0, 0) — wins because ID beats everything below */
#submit-btn {
  background: red;
}

/* Rule 2: (0, 0, 2, 0) — two classes, still loses to one ID */
.form .btn-primary {
  background: blue;
}

/* Rule 3: (0, 0, 1, 1) — one class + one element, lowest */
button.btn-primary {
  background: green;
}

/* Result: the button is red — the ID selector wins */
/* Even though Rule 3 appears last, specificity > source order */

!important

!important overrides all specificity calculations. It creates a separate layer that always wins over normal declarations. If two rules both use !important, then specificity is compared between them. It's a last resort — using it regularly creates maintenance nightmares.

The :where() pseudo-class

:where() is unique because it always contributes zero specificity, regardless of what's inside it. This is useful for writing default styles that are easy to override. Compare it with :is(), which takes the specificity of its most specific argument.

/* :where() — specificity is (0, 0, 0, 0) regardless of contents */
:where(#header .nav) a {
  color: blue; /* Easy to override with just: a { color: red; } */
}

/* :is() — takes specificity of most specific argument */
:is(#header, .nav) a {
  color: blue; /* Specificity: (0, 1, 0, 1) because #header is the most specific */
}

Universal selector and combinators

The universal selector (*), combinators (>, +, ~, ), and the negation pseudo-class container (:not() itself) contribute zero specificity. However, the arguments inside :not() do count.

Specificity bugs are one of the most common CSS issues in production codebases. Interviewers ask this to check whether you can debug styling conflicts without blindly adding !important, whether you understand how the cascade resolves competing rules, and whether you write maintainable selectors that don't create specificity wars. It's a fundamental CSS concept that separates developers who truly understand the language from those who just trial-and-error their way through styling.