CSS Specificity Calculator

CSS specificity is the weight algorithm browsers use to resolve conflicting CSS declarations targeting the same HTML element. When two or more selectors match an element, the declaration associated with the most specific selector wins and applies its styles.

A Simple Analogy: Think of specificity like weight classes in boxing or military ranks. A single heavyweight outmatches any number of lightweights, just as a single general outranks any battalion of privates. In CSS, an ID selector outranks any number of classes, and a class outranks any number of bare element tags.

Specificity is measured as a 3-part tuple: (A, B, C). Each category contributes to its designated column:

Comparison Rule: Tuples are compared lexicographically from left to right. Column A is evaluated first. If tied, Column B is evaluated. Only if both A and B are equal is Column C checked.

These parts contribute [0, 0, 0] to specificity:

• Universal selector: * adds 0
• Combinators: Descendant (space), child (>), adjacent sibling (+), and general sibling (~) add 0
• The zero-specificity pseudo-class: :where(...) always contributes [0, 0, 0] regardless of what is inside it.

CRUCIAL WARNING: Specificity is NOT base-10!
A very common beginner trap is thinking (0, 1, 0) = 10 and (0, 0, 11) = 11. Numbers in CSS specificity never carry over into adjacent columns. 11 classes (0 - 11 - 0) will never beat 1 ID (1 - 0 - 0).

Modern functional pseudo-classes follow recursive evaluation rules specified in CSS Selectors Level 4:

Selector specificity is only one step in the broader CSS Cascade algorithm. The definitive order of precedence is:

1. !important declarations: Overrides inline styles and normal specificity rules.
2. Inline styles: Properties set directly on elements (style="...") beat all external and internal stylesheet rules.
3. Selector Specificity: The highest (A, B, C) tuple wins.
4. Source Order: When specificity is identical, the rule appearing later in the CSS wins.

Important note: When !important is applied to both conflicting rules, the standard specificity comparison still decides which one wins!

• Keep specificity flat and low: Prefer single or double class selectors (e.g., BEM .card__title). Low specificity ensures styles can be overridden cleanly anywhere.
• Avoid IDs for styling: Reserve IDs for HTML anchors and JS hooks. Using an ID in CSS forces you to use another ID or !important to override it.
• Avoid !important: Treat !important as a code smell. It creates maintainability deadlocks.
• Use :where() for resets and base styles: Wrapping design system primitives in :where(...) keeps their specificity at 0, allowing consumer components to override them without resistance.
• Adopt CSS Cascade Layers (@layer): Use layers (e.g., @layer reset, base, components, utilities;) to control priority across large codebases without inflating selector specificity.
• Keep selector chains short: Avoid over-qualifying elements like div.card ul.list li.item; write .list__item instead.

• Over-qualifying selectors: Writing ul.nav or div.sidebar instead of just .nav or .sidebar. This adds unnecessary element specificity and couples your CSS to HTML tag choices.
• Chaining excessive classes: Writing .card.featured.active.primary.large to win an override battle rather than refactoring CSS architecture.
• Forgetting that source order breaks ties: If two selectors have identical specificity (e.g., both 0 - 1 - 0), whichever rule comes later in the stylesheet wins.
• Assuming :where() takes argument specificity: :where() is specifically designed to always have 0 specificity; use :is() if you want argument specificity.