Overview
Calculate CSS selector specificity instantly
Specificity is how the browser decides which CSS rule wins when two rules target the same element. It is expressed as a triple of three numbers, often written a, b, c. The first number counts ID selectors, the second counts classes, attributes, and pseudo-classes, and the third counts element types and pseudo-elements.
This calculator parses any selector and shows its specificity triple plus a breakdown of exactly what was counted. Paste a single selector or a comma separated list, and it highlights the most specific part. Everything runs in your browser.
Step-by-step
How to use the specificity calculator
- 1
Type a selector
Enter any CSS selector, for example.nav li a:hoveror#main .card h2. The result updates as you type. - 2
Read the triple
The three numbers are shown as a, b, c. Higher numbers, compared from left to right, mean a more powerful selector. - 3
Check the breakdown
Each counted token is tagged so you can see which part landed in which bucket and why your rule is winning or losing.
Background
How specificity is counted
The browser walks the selector and sorts each simple piece into one of three buckets. ID selectors go into a. Class selectors, attribute selectors like [type="text"], and pseudo-classes like :hover go into b. Type selectors such as div and pseudo-elements like ::before go into c. The universal selector and combinators add nothing.
Comparison is left to right
Specificity is not a single base ten number. The browser compares a first. Only if a ties does it look at b, and only if b ties does it look at c. This is why one ID outranks any number of classes: a single 0, 1, 0 selector beats a 0, 0, 99 selector but loses to 1, 0, 0.
Inline styles and !important
A style attribute written directly on an element outranks every selector based rule. Above even that sits !important, which overrides normal declarations regardless of specificity. Use both sparingly, because they make stylesheets hard to maintain.
Use cases
When specificity matters
Debugging override bugs
Find out why a rule is not applying by comparing the specificity of competing selectors.
Refactoring stylesheets
Flatten deeply nested selectors that have crept up in specificity and become hard to override.
Building component libraries
Keep selector specificity low and consistent so consumers can style components without fighting.
Teaching the cascade
Show students exactly how the a, b, c triple decides the winner between two rules.
Auditing legacy CSS
Spot overpowered ID and !important rules that block clean theming and dark mode.
Writing utility classes
Confirm that single class utilities stay at 0, 1, 0 so they layer predictably.
Tips and best practices
- Prefer classes over IDs in CSS so your specificity stays low and easy to override.
- Avoid long descendant chains. Each extra element or class raises specificity needlessly.
- Reach for !important only as a last resort. It is hard to undo later.
- When two rules tie on specificity, the one written later in the source wins.
- Keep utility class systems flat so every utility has the same low specificity.
Common questions
What does a result like 0, 2, 2 mean?
It means zero ID selectors, two from the class, attribute, and pseudo-class bucket, and two element or pseudo-element selectors. The selector .nav li a:hover produces exactly this triple.
Does the universal selector add specificity?
No. The universal selector * and combinators such as >, +, and ~ contribute nothing to specificity. Only the simple selectors they join are counted.
How are pseudo-elements counted?
Pseudo-elements like ::before and ::after count as element selectors in the c bucket, while pseudo-classes like :hover count in the b bucket. The double colon and single colon are the giveaway.
Why is my more detailed selector still losing?
Because comparison is left to right. A competing rule with even one ID selector beats yours no matter how many classes and elements you add, since the a column is checked first.
100% private