Calculate CSS Specificity for Any Selector Correctly
When two CSS rules target the same element and set the same property, the browser has to decide which one wins, and specificity is the mechanism it uses before falling back to source order. Specificity is not a single number but a triple, usually written as three values in the form A, B, C. The A column counts ID selectors, the B column counts classes, attribute selectors, and pseudo-classes, and the C column counts element type selectors and pseudo-elements. The columns are compared from left to right, so any selector with a higher A beats every selector with a lower A regardless of the other columns, exactly like comparing version numbers. This calculator parses a selector and reports that triple, and just as importantly it handles the modern functional pseudo-classes whose specificity rules trip up almost everyone.
The counting rules are precise, and the functional pseudo-classes are where the subtlety lives. The universal selector and combinators such as the child, descendant, and sibling combinators contribute nothing to specificity — they are structural and count as zero across all three columns. The where pseudo-class is the special one: it always contributes zero specificity no matter what you put inside it, which is what makes it perfect for low-priority defaults that are easy to override. By contrast the is, not, and has pseudo-classes take on the specificity of their single most specific argument. So a not containing an ID contributes to the A column, while a not containing only an element contributes to the C column. This calculator applies each of these rules while parsing, so a selector mixing an ID, a couple of classes, and an element resolves to the correct triple rather than a naive count that ignores the functional wrappers.
Two worked examples make the rules tangible. Consider the selector that combines an ID, a class, and an element type — an ID selector, then a descendant class selector, then a descendant element. It has one ID, one class, and one element, so the triple is one, one, one. Now consider a selector built from the is pseudo-class wrapping two alternatives, one of which is an ID and the other a plain element. Because is adopts the specificity of its most specific argument, and an ID outweighs an element, the whole thing resolves to one, zero, zero — the ID dominates and the element inside the is contributes nothing extra. Swap that is for a where wrapping the same arguments and the triple collapses to zero, zero, zero, because where is defined to contribute nothing regardless of its contents. Seeing these side by side is the fastest way to understand why where has become the recommended tool for authoring overridable base styles.
The practical uses are all about diagnosing the cascade. A developer whose style is not applying can paste both the winning selector and their own selector, compare the triples, and immediately see that the other rule has a higher A or B column. Someone building a design system can verify that their base layer uses low-specificity selectors, ideally wrapped in where, so that component and utility styles override them without a specificity war. A person refactoring a large stylesheet can check whether replacing an ID selector with a class will change which rules win. And anyone learning CSS can build intuition by trying selectors and watching how adding an ID, a class, or a functional pseudo-class shifts the triple, which is far more effective than memorizing the rules from a table.
A few tips keep specificity manageable. Do not collapse the triple into a single base-ten number by treating the columns as digits; the columns do not carry, so eleven classes never equal one ID, and pretending they do leads to wrong conclusions. Reach for the where pseudo-class when you want a rule that is easy to override, and avoid ID selectors in reusable component styles because their high A column makes them hard to beat without another ID. Remember that inline styles and the important flag sit outside the ordinary triple and override it, so if a rule still will not apply after you have matched specificity, check for those. Finally, when two selectors have identical specificity, the later one in source order wins, so ordering still matters after specificity is tied. Because this calculator runs entirely in your browser, you can test as many selectors as you like with no signup and nothing leaving your device.
