By Rohit V.8 min readArticle
CSS Specificity Explained — Why Your Styles Lose
TF
ToolsFuel Team
Web development tools & tips
Photo by Unsplash on Unsplash
Table of Contents
Why a Rule You Wrote Gets Ignored
> Quick answer: CSS specificity is the scoring system browsers use to decide which competing rule wins when several target the same element. It's calculated as a three-part value — (IDs, classes, elements), sometimes written as a four-part value with inline styles in front. Inline `style=""` attributes beat everything in the stylesheet. An ID selector (`#header`) outranks any number of classes (`.nav`), which in turn outrank any number of element selectors (`div`, `p`). You compare left to right: a rule with one ID (1,0,0) beats a rule with ten classes (0,10,0), because the ID column wins before the class column is even considered. When two rules have *identical* specificity, the one that comes later in the CSS wins — that's the tiebreaker. And `!important` overrides the normal calculation entirely, which is exactly why you should avoid leaning on it.
Every developer hits this. You write `.button { color: blue; }`, refresh the page, and the button is stubbornly still red. The CSS is right there. The syntax is fine. But something else — usually a more specific selector you forgot about — is winning the fight. Once you understand *how* the browser scores that fight, the mystery evaporates and you stop adding `!important` out of frustration.
Let me walk through how specificity is actually calculated, the gotchas that catch people, and how to keep it low so your styles stay predictable.
Every developer hits this. You write `.button { color: blue; }`, refresh the page, and the button is stubbornly still red. The CSS is right there. The syntax is fine. But something else — usually a more specific selector you forgot about — is winning the fight. Once you understand *how* the browser scores that fight, the mystery evaporates and you stop adding `!important` out of frustration.
Let me walk through how specificity is actually calculated, the gotchas that catch people, and how to keep it low so your styles stay predictable.
How the Score Is Calculated
Specificity is computed as a tuple of numbers. The most useful way to think about it is three columns — (IDs, classes, elements) — though you'll also see a four-column version that prepends inline styles. Each selector contributes to one column:
- ID selectors (`#main`, `#nav`) add to the first column. - Class selectors (`.card`), attribute selectors (`[type="text"]`), and pseudo-classes (`:hover`, `:focus`, `:nth-child()`) add to the second column. - Element selectors (`div`, `a`, `h1`) and pseudo-elements (`::before`, `::after`) add to the third column.
Then you compare the columns left to right, like version numbers. A few worked examples:
- `h1` → (0, 0, 1) - `.title` → (0, 1, 0) - `nav a` → (0, 0, 2) — two elements - `.nav a` → (0, 1, 1) — one class, one element - `#header .nav a` → (1, 1, 1)
The comparison is column by column, and a higher number in an earlier column wins outright regardless of what's in the later columns. This is the part that surprises people: `#header` at (1, 0, 0) beats `.nav .menu .item .link .active` at (0, 5, 0). One ID outranks five classes, because the ID column is compared first and 1 beats 0 before the class column ever matters. Specificity is not a sum — you don't add the numbers up into a single total. It's a left-to-right comparison, column by column.
The universal selector (`*`) and combinators (`>`, `+`, `~`, the descendant space) add nothing to specificity. They affect *what* gets matched but not how much weight the rule carries. The MDN specificity reference has an exhaustive breakdown if you want to check an unusual selector, but the (IDs, classes, elements) model covers the vast majority of real-world cases.
A couple of modern selectors are worth flagging because they behave unusually. The `:not()`, `:is()`, and `:has()` pseudo-classes don't add specificity *themselves* — instead they take on the specificity of their most specific argument. So `:is(.a, #b)` counts as an ID (because `#b` is the heaviest thing inside), which can quietly inflate a rule's weight more than you'd expect from looking at it. The opposite is `:where()`, which always contributes zero specificity no matter what's inside it. That makes `:where()` genuinely useful for writing low-specificity base styles that are trivially easy to override later — I've started using it for default component styles precisely because it sidesteps the whole specificity arms race. If you wrap your resets and defaults in `:where()`, they sit at the bottom of the cascade and anything you write afterward wins automatically.
- ID selectors (`#main`, `#nav`) add to the first column. - Class selectors (`.card`), attribute selectors (`[type="text"]`), and pseudo-classes (`:hover`, `:focus`, `:nth-child()`) add to the second column. - Element selectors (`div`, `a`, `h1`) and pseudo-elements (`::before`, `::after`) add to the third column.
Then you compare the columns left to right, like version numbers. A few worked examples:
- `h1` → (0, 0, 1) - `.title` → (0, 1, 0) - `nav a` → (0, 0, 2) — two elements - `.nav a` → (0, 1, 1) — one class, one element - `#header .nav a` → (1, 1, 1)
The comparison is column by column, and a higher number in an earlier column wins outright regardless of what's in the later columns. This is the part that surprises people: `#header` at (1, 0, 0) beats `.nav .menu .item .link .active` at (0, 5, 0). One ID outranks five classes, because the ID column is compared first and 1 beats 0 before the class column ever matters. Specificity is not a sum — you don't add the numbers up into a single total. It's a left-to-right comparison, column by column.
The universal selector (`*`) and combinators (`>`, `+`, `~`, the descendant space) add nothing to specificity. They affect *what* gets matched but not how much weight the rule carries. The MDN specificity reference has an exhaustive breakdown if you want to check an unusual selector, but the (IDs, classes, elements) model covers the vast majority of real-world cases.
A couple of modern selectors are worth flagging because they behave unusually. The `:not()`, `:is()`, and `:has()` pseudo-classes don't add specificity *themselves* — instead they take on the specificity of their most specific argument. So `:is(.a, #b)` counts as an ID (because `#b` is the heaviest thing inside), which can quietly inflate a rule's weight more than you'd expect from looking at it. The opposite is `:where()`, which always contributes zero specificity no matter what's inside it. That makes `:where()` genuinely useful for writing low-specificity base styles that are trivially easy to override later — I've started using it for default component styles precisely because it sidesteps the whole specificity arms race. If you wrap your resets and defaults in `:where()`, they sit at the bottom of the cascade and anything you write afterward wins automatically.
The Tiebreaker and the !important Escape Hatch
Photo by Unsplash on Unsplash
So what happens when two rules have the *exact same* specificity? This is where a rule people half-remember actually matters.
When specificity ties, source order decides — the later rule wins. If you have:
``` .button { color: blue; } .button { color: green; } ```
Both are (0, 1, 0), a perfect tie, so the second one wins and the button is green. This is the "proximity in the source" tiebreaker, and it's why the order of your stylesheets and rules matters. It's also why a style imported *after* yours can quietly override it without being any more specific — it just came later. I've chased this exact bug when a component library's CSS loaded after mine and flattened my overrides despite identical specificity.
Then there's `!important`, the nuclear option:
``` .button { color: blue !important; } ```
Adding `!important` to a declaration lifts it *out* of the normal specificity contest entirely. An important declaration beats any non-important one, no matter how specific. It feels like a quick win, and that's exactly the trap. The moment you use `!important` to beat a stubborn rule, the *next* person (often future you) has to use `!important` to beat *that*, and now you've got an escalating arms race where the only way to win is another `!important`. I've inherited stylesheets where half the declarations were `!important` because everyone was fighting everyone else, and at that point specificity stops meaning anything — you're just stacking overrides.
My honest take: reach for `!important` only when you genuinely can't control the other CSS — overriding a third-party widget you can't edit, for instance. For your own code, if you feel the urge to use it, that's a signal your selectors have gotten too specific and it's time to refactor, not to escalate.
When specificity ties, source order decides — the later rule wins. If you have:
``` .button { color: blue; } .button { color: green; } ```
Both are (0, 1, 0), a perfect tie, so the second one wins and the button is green. This is the "proximity in the source" tiebreaker, and it's why the order of your stylesheets and rules matters. It's also why a style imported *after* yours can quietly override it without being any more specific — it just came later. I've chased this exact bug when a component library's CSS loaded after mine and flattened my overrides despite identical specificity.
Then there's `!important`, the nuclear option:
``` .button { color: blue !important; } ```
Adding `!important` to a declaration lifts it *out* of the normal specificity contest entirely. An important declaration beats any non-important one, no matter how specific. It feels like a quick win, and that's exactly the trap. The moment you use `!important` to beat a stubborn rule, the *next* person (often future you) has to use `!important` to beat *that*, and now you've got an escalating arms race where the only way to win is another `!important`. I've inherited stylesheets where half the declarations were `!important` because everyone was fighting everyone else, and at that point specificity stops meaning anything — you're just stacking overrides.
My honest take: reach for `!important` only when you genuinely can't control the other CSS — overriding a third-party widget you can't edit, for instance. For your own code, if you feel the urge to use it, that's a signal your selectors have gotten too specific and it's time to refactor, not to escalate.
Keeping Specificity Low and Sane
The best way to win specificity fights is to not have them. Keep your selectors flat and your scores low, and the cascade becomes predictable instead of adversarial.
A few habits that have saved me real debugging time:
- Prefer a single class over deep nesting. `.card-title` is (0, 1, 0) and easy to override. `#content .sidebar .card .header .title` is (1, 4, 0) and a nightmare — anything that needs to beat it has to be even more baroque. Flat, single-class selectors keep everything roughly equal and predictable. - Avoid styling by ID. IDs jump you straight to the (1, x, x) tier, which is hard to override without another ID or `!important`. Reserve IDs for JavaScript hooks and anchors; style with classes. This one change prevents most specificity headaches. - Lean on source order. Since equal-specificity ties break by order, structure your stylesheet so base styles come first and overrides come later. When everything is the same low specificity, *position* becomes your control knob — and that's far easier to reason about than juggling selector weights. - Watch third-party CSS load order. If a library's styles override yours, the fix is often loading your CSS after theirs rather than cranking up specificity. Order beats brute force.
Methodologies like BEM exist largely to solve this — they push you toward flat, single-class selectors so specificity stays uniform across your whole codebase. You don't have to adopt a whole naming system, but the underlying idea (keep selectors shallow and class-based) is worth stealing regardless.
When you *are* stuck in a specificity fight, your browser's dev tools are the fastest way out. Inspect the element and open the Styles panel: it lists every rule that targets that element, with the winning declarations at the top and the overridden ones struck through. A property with a line through it is one that lost the cascade, and hovering it usually tells you which rule beat it. That strikethrough is the single most useful debugging signal in CSS — it turns "why isn't my style applying" from a guessing game into a two-second read. I'll often spot an inline `style` attribute or a sneaky ID selector right there that I'd completely forgotten about. Some dev tools even surface the computed specificity directly, so you can see (1,2,0) versus (0,3,0) at a glance and know instantly why one is winning.
A related habit: when you find yourself writing an oddly long selector just to beat something, stop and ask whether the *other* rule is the real problem. Nine times out of ten, lowering the specificity of the rule you're fighting is cleaner than raising the specificity of the rule you're writing. Chasing higher and higher specificity is how stylesheets rot; pulling specificity *down* is how they stay maintainable. I treat a creeping specificity score the way I treat a creeping function — it's a smell telling me to refactor before it gets worse.
If you're also wrangling color values across all this CSS — converting a hex from a design tool into the rgba your stylesheet needs — the ToolsFuel color picker and converter handles the format juggling, and the rest of the free developer tools cover the small utilities that come up while you're deep in a stylesheet. When the color formats themselves are the confusing part, I sorted out the differences in HEX, RGB, HSL, and OKLCH CSS color formats. Keep specificity low, let source order do the tiebreaking, and your CSS stops feeling like a fight you keep losing.
A few habits that have saved me real debugging time:
- Prefer a single class over deep nesting. `.card-title` is (0, 1, 0) and easy to override. `#content .sidebar .card .header .title` is (1, 4, 0) and a nightmare — anything that needs to beat it has to be even more baroque. Flat, single-class selectors keep everything roughly equal and predictable. - Avoid styling by ID. IDs jump you straight to the (1, x, x) tier, which is hard to override without another ID or `!important`. Reserve IDs for JavaScript hooks and anchors; style with classes. This one change prevents most specificity headaches. - Lean on source order. Since equal-specificity ties break by order, structure your stylesheet so base styles come first and overrides come later. When everything is the same low specificity, *position* becomes your control knob — and that's far easier to reason about than juggling selector weights. - Watch third-party CSS load order. If a library's styles override yours, the fix is often loading your CSS after theirs rather than cranking up specificity. Order beats brute force.
Methodologies like BEM exist largely to solve this — they push you toward flat, single-class selectors so specificity stays uniform across your whole codebase. You don't have to adopt a whole naming system, but the underlying idea (keep selectors shallow and class-based) is worth stealing regardless.
When you *are* stuck in a specificity fight, your browser's dev tools are the fastest way out. Inspect the element and open the Styles panel: it lists every rule that targets that element, with the winning declarations at the top and the overridden ones struck through. A property with a line through it is one that lost the cascade, and hovering it usually tells you which rule beat it. That strikethrough is the single most useful debugging signal in CSS — it turns "why isn't my style applying" from a guessing game into a two-second read. I'll often spot an inline `style` attribute or a sneaky ID selector right there that I'd completely forgotten about. Some dev tools even surface the computed specificity directly, so you can see (1,2,0) versus (0,3,0) at a glance and know instantly why one is winning.
A related habit: when you find yourself writing an oddly long selector just to beat something, stop and ask whether the *other* rule is the real problem. Nine times out of ten, lowering the specificity of the rule you're fighting is cleaner than raising the specificity of the rule you're writing. Chasing higher and higher specificity is how stylesheets rot; pulling specificity *down* is how they stay maintainable. I treat a creeping specificity score the way I treat a creeping function — it's a smell telling me to refactor before it gets worse.
If you're also wrangling color values across all this CSS — converting a hex from a design tool into the rgba your stylesheet needs — the ToolsFuel color picker and converter handles the format juggling, and the rest of the free developer tools cover the small utilities that come up while you're deep in a stylesheet. When the color formats themselves are the confusing part, I sorted out the differences in HEX, RGB, HSL, and OKLCH CSS color formats. Keep specificity low, let source order do the tiebreaking, and your CSS stops feeling like a fight you keep losing.
Frequently Asked Questions
How is CSS specificity calculated?
Specificity is a tuple of numbers, usually thought of as three columns: (IDs, classes, elements). ID selectors add to the first column, classes/attributes/pseudo-classes to the second, and elements/pseudo-elements to the third. You compare the columns left to right like version numbers — a higher value in an earlier column wins outright. It's not a sum; one ID (1,0,0) beats any number of classes (0,10,0).
Why is my CSS rule being ignored?
Almost always because another selector targeting the same element has higher specificity, or an equally specific rule comes later in the source order. Open your browser's dev tools and inspect the element — it shows which rules apply and which are overridden, with the winning declaration at the top. Check for an ID selector or an inline style quietly outranking your class.
Does an ID always beat a class in CSS?
Yes. A single ID selector (1,0,0) outranks any number of class selectors because the ID column is compared before the class column. That's why styling by ID causes so many override headaches — anything that needs to beat it requires another ID or !important. The common advice is to reserve IDs for JavaScript hooks and anchors, and style everything with classes instead.
What happens when two CSS rules have the same specificity?
Source order breaks the tie — the rule that appears later in the CSS wins. This is why the order your stylesheets load matters, and why a third-party library loaded after your CSS can override your styles without being any more specific. Structuring base styles first and overrides later lets you use position, rather than escalating specificity, to control which rule applies.
Should I use !important to fix a stubborn style?
Avoid it in your own code. !important lifts a declaration out of the normal specificity contest, so it beats everything — but then the only way to override it is another !important, creating an escalating arms race. Reserve it for cases where you genuinely can't edit the other CSS, like a third-party widget. If you feel the urge to use it on your own styles, that's a sign your selectors are too specific and need refactoring. See the [ToolsFuel tools directory](/tools) for utilities that help while you clean up.
Try ToolsFuel
23+ free online tools for developers, designers, and everyone. No signup required.
Browse All Tools