CSS Specificity Calculator

When two CSS rules target the same element, the cascade picks the rule with higher specificity — counted as (ID, class/attr/pseudo-class, type/pseudo-element). This tool parses your selector, weights every part (#id +1·0·0, .class +0·1·0, div +0·0·1), then walks pseudo-classes like :is(), :not(), :has() (highest argument wins) and :where() (always 0). Drop in two selectors to see which one wins the cascade and by how much, so you can stop guessing why a rule isn't applying.

The three numbers are compared left to right, not added up, and that is the part most explanations skip. A single ID beats any number of classes, so #header outranks a selector carrying a hundred class names; the columns never carry. Thinking of specificity as a base-10 number works until someone writes eleven classes, and then it stops.

Specificity is also only the third tiebreak, not the first. An !important declaration wins over any normal one regardless of the selector, inline styles sit above normal author rules, and cascade layers are consulted before specificity is ever compared. When two declarations end up equal on all of that, the last one in source order wins. A rule that refuses to apply despite the higher score is usually losing on one of those earlier rounds rather than on this one.

:where() exists precisely to opt out of this arithmetic: it always contributes zero, which is what makes it the right tool for library defaults that authors should be able to override with a single class. :is() and :not() instead take the specificity of their most specific argument, so :is(h1, #title) is as heavy as #title even when it matches an h1.

The count describes the selector, not the match. Two selectors can score identically and still target different elements, and a higher score on paper means nothing if the rule never matches the element you are looking at.