You write a CSS rule. You refresh the page. Nothing changes. You add the same property again, a little more forcefully. Still nothing. You add !important in frustration, and suddenly it works, but now you have no idea why the original rule failed, and you have planted a small bomb in your stylesheet that will confuse you six months from now.
Almost every front-end developer has lived this exact scenario. The culprit is almost always CSS specificity: the scoring system browsers use to decide which rule wins when multiple rules target the same element. Once you understand how the scoring works, those mysterious failures become predictable, and you can stop reaching for !important as a first resort.
This guide breaks down specificity in plain language, walks through the scoring with real examples, and shows you the common traps that cause styles to silently lose.
When two or more CSS rules set the same property on the same element, the browser needs a tiebreaker. Specificity is that tiebreaker. Each selector gets a score based on what it contains, and the rule with the highest score wins. If scores are equal, the rule that appears later in the stylesheet wins.
Specificity is calculated in three categories, often written as a triplet like (0, 1, 2). The categories are: inline styles, IDs, and then classes, attributes, and pseudo-classes grouped together, followed by elements and pseudo-elements. A common shorthand counts them as hundreds, tens, and ones, but the triplet notation is more accurate because the categories do not actually carry over the way decimal digits do.
Here is the scoring in detail. Inline styles, written directly in a style attribute, outrank everything from stylesheets. Each ID selector, like #header, adds one to the ID column. Each class selector (.button), attribute selector ([type="text"]), and pseudo-class (:hover) adds one to the middle column. Each element selector (p, div) and pseudo-element (::before) adds one to the last column. The universal selector (*) and combinators like > and + add nothing.
Let us score some real selectors. The selector p has a specificity of (0, 0, 1): zero IDs, zero classes, one element. The selector .intro has (0, 1, 0). The selector #main has (1, 0, 0). Already you can see the hierarchy: a single ID beats any number of classes, and a single class beats any number of elements.
Compound selectors add up their parts. The selector ul.nav li.active scores (0, 2, 2): two classes (.nav and .active) plus two elements (ul and li). The selector #sidebar .widget h2 scores (1, 1, 1). When comparing, the browser looks at the leftmost column first. (1, 0, 0) beats (0, 99, 99) every time, because one ID outweighs any number of classes.
Consider a concrete conflict. Suppose your stylesheet has .button { background: blue; } with specificity (0, 1, 0), and later #signup .button { background: green; } with (1, 1, 0). The button inside #signup will be green, because the ID in the second selector wins regardless of order. If you then write .form .panel .button { background: red; } with (0, 3, 0), it still loses to the ID selector. This is the moment most developers discover specificity the hard way.
A CSS minifier will shrink your stylesheet for faster loading, but it preserves selector structure exactly, so minification never changes specificity outcomes. The scores are determined by your selectors, not by formatting.
The !important declaration sits outside the normal specificity system. A rule with !important beats any rule without it, regardless of selector scores. When two !important rules conflict, normal specificity scoring applies between them, and then source order.
This sounds like a convenient escape hatch, and occasionally it is. But !important creates a new layer of conflicts that can only be resolved by more !important declarations, leading to arms races in large codebases. It also makes debugging harder, because the winning rule is no longer determined by the selector logic you can read.
Reserve !important for genuine exceptions: utility classes that must always apply, overrides for third-party styles you cannot edit, and accessibility fixes. If you find yourself adding !important to your own component styles, treat it as a signal that your specificity architecture needs attention, not as a solution.
Certain patterns reliably cause specificity headaches. Recognizing them saves hours of debugging.
Writing div.container instead of .container adds an unnecessary element to the score, making the rule (0, 1, 1) instead of (0, 1, 0). That seems harmless until someone needs to override it and discovers their plain class selector loses. Keep selectors as simple as they can be while remaining accurate.
IDs have their place, but using them for styling creates rules with (1, 0, 0) specificity that are extremely hard to override. Since IDs must be unique per page, ID-styled components cannot be reused anyway. Prefer classes for styling and reserve IDs for JavaScript hooks and anchor targets.
Selectors like .page .content .article .body p accumulate specificity with every level. Each level also tightly couples your CSS to your HTML structure, so markup changes break styles. Most of the time, a single well-named class on the target element does the job with far less specificity.
Libraries and frameworks ship with their own specificity choices. When your styles lose to a framework's, check the framework's selectors before escalating. Often the fix is matching or slightly exceeding their specificity with a clean selector, not piling on !important declarations.
The best specificity strategy is keeping scores low and flat across your codebase. When most selectors are single classes at (0, 1, 0), conflicts are rare and overrides are predictable: later rules win, which is easy to reason about.
Browser developer tools are the fastest way to resolve a specificity mystery. Inspect the element, open the Styles panel, and look at which rules are struck through. The panel shows selectors in order of specificity, with the winning rule on top. You can see exactly why your rule lost and what score it needs to beat.
A useful habit is computing specificity before you write an override. If the winning rule is #nav .link at (1, 1, 0), you know your override needs an ID or a fundamentally different approach, like restructuring the CSS. Guessing wastes time; the dev tools give you the numbers.
When working with minified production CSS, keep a readable source version for debugging. An HTML minifier handles your markup the same way, but for CSS specifically, source maps or an unminified development build make specificity investigation far easier.
No. Specificity is checked first, and source order only breaks ties between rules with equal specificity. A higher-specificity rule earlier in the stylesheet always beats a lower-specificity rule later in it. Order only matters when the scores are identical.
Inline styles are treated as having the highest specificity category, above IDs. A style attribute effectively scores (1, 0, 0, 0) in the four-column model. Only an !important declaration in a stylesheet can override a normal inline style, which is one reason inline styles make maintenance difficult.
Yes, in narrow cases: utility classes that must always win, overriding third-party CSS you cannot modify, print stylesheets, and accessibility-related overrides. The problem is not !important itself but using it as a substitute for understanding specificity, which leads to unmaintainable cascades of escalating declarations.
Yes. Pseudo-classes such as :hover, :focus, :nth-child(), and :not() each count the same as a class selector in the middle specificity column. Note that :not() itself adds nothing, but the selector inside it does count. Pseudo-elements like ::before and ::after count as elements in the last column.
Count IDs, then classes, attributes, and pseudo-classes, then elements and pseudo-elements, and write the three numbers as a triplet. Compare triplets left to right. Many developers also use online specificity calculators, and browser dev tools display the winning order directly, which is often faster than hand calculation.
CSS specificity stops being mysterious the moment you start thinking in scores. Count the IDs, classes, and elements in competing selectors, and the winner becomes obvious before you even refresh the page. Keep your selectors flat, reserve IDs for behavior rather than styling, and reach for !important only when you truly mean "this must win no matter what." For a leaner stylesheet that still behaves exactly the same, run your CSS through Seovaro's free CSS minifier and ship the smaller file with confidence.
