Fixing CSS Specificity Conflicts

How specificity problems show up

Specificity trouble rarely announces itself. You notice it through habits that build up in a codebase:

• A style change only "takes" when you add !important.
• Selectors such as #main .content .sidebar .widget ul li a, often produced by nesting in Sass or Less.
• Copies of the same rule with one more class added, each written to beat the one before.
• A component that looks right on one page and wrong on another, because a page-level rule with an ID outranks it there.
• Utility classes such as .mt-0 or .text-center that do nothing on some elements.
• Theme updates that "break" your custom styles, when really the theme's selectors got slightly stronger than yours.

The CSS Checker scans for specificity issues such as heavy use of !important and overly strong selectors. Treat its list as a map of where the fights are happening; the rest of this guide is about ending them rather than winning each one.

How the browser decides which rule wins

Specificity is only one step in the cascade. When two declarations set the same property on the same element, the browser compares them in this order and stops at the first difference:

1. Origin and importance. Your stylesheet beats the browser default; an !important declaration beats a normal one.
2. Cascade layer. For normal declarations, a later layer beats an earlier one, and styles not in any layer beat all layers.
3. Specificity. The selector with the higher score wins.
4. Order of appearance. If everything above is equal, the declaration that comes later wins.

Styles written in an element's style attribute outrank any selector in a stylesheet, which is why inline styles added by JavaScript or a page builder are so hard to override without !important.

Reading a specificity score

A selector's specificity is three numbers, compared from left to right: IDs, then classes (including attribute selectors and pseudo-classes), then element names (including pseudo-elements). The first column that differs decides it; a single ID beats any number of classes.

The same "strongest argument" rule applies to :not() and :has(). Native CSS nesting behaves as if the parent selector were wrapped in :is(), so nesting an ID-based parent quietly gives every child rule an ID's weight.

Tracing a conflict in developer tools

Pick one concrete symptom, such as "the newsletter button is grey instead of green", and trace it:

1. Right-click the element and choose Inspect.
2. In the Styles pane, find the property you expected to apply. It will be struck through.
3. Scroll up the pane to find the declaration that is not struck through. That is the winner, and the file and line are shown next to it.
4. Hover over both selectors to compare their specificity, and check whether either sits inside an @layer block or carries !important.
5. Open the Computed pane and expand the property to see every declaration that tried to set it, in the order the browser considered them.

Write down the pair: the rule you wanted and the rule that won. After a handful of these you usually see a pattern, such as a theme file using IDs, a plugin using long chains, or a legacy stylesheet sprinkling !important. That pattern tells you which structural fix to apply first.

Cascade layers: controlling order without raising scores

Cascade layers are the most useful tool for specificity problems added to CSS in years, and they are supported in all current major browsers. A layer is a named bucket of styles. You declare the order of the buckets once, and from then on a rule in a later layer beats a rule in an earlier layer, however strong the earlier rule's selector is.

/* Declare the order first, at the very top of the first stylesheet */
@layer reset, vendor, base, components, utilities;

@layer reset {
  *, *::before, *::after { box-sizing: border-box; }
}

@layer base {
  a { color: #1d4ed8; }
}

@layer components {
  .card a { color: inherit; }
}

@layer utilities {
  .text-danger { color: #b91c1c; }
}

With this structure, .text-danger on a link inside a card is red, even though .card a has higher specificity, because the utilities layer comes later. Specificity still matters inside each layer, but it no longer decides fights between layers.

Putting code you do not control into a layer

You can place a whole imported stylesheet into a layer, which is ideal for frameworks and plugin CSS with aggressive selectors:

@import url("vendor/datepicker.css") layer(vendor);

Every rule in that file now loses to your base, component and utility layers, however many IDs it uses.

Two rules that surprise people

• Unlayered styles win. Any normal rule not inside a layer beats every layered rule. That is handy during migration, because your existing CSS keeps working, but it also means a forgotten unlayered file can override everything.
• Important declarations reverse the order. An !important declaration in an early layer beats an !important declaration in a later layer, and layered important declarations beat unlayered important ones. This lets a reset layer protect something like a hidden attribute with !important that later layers cannot undo.

The fix, step by step

A before and after

Here is a typical tangle from a small business site, where a promotional button has to fight the theme's link styles:

/* Theme */
#page .entry-content a { color: #2563eb; text-decoration: underline; }

/* Someone's fix */
.promo-box .btn-offer { color: #fff; }                     /* loses: 0,2,0 vs 1,1,1 */
#page .promo-box a.btn-offer { color: #fff; }              /* wins, now 1,2,1 */
.btn-offer.is-disabled { color: #9ca3af !important; }     /* needed to beat the line above */

And the same result using layers and flat selectors:

@layer theme, components, states;

@import url("theme.css") layer(theme);

@layer components {
  .btn-offer { color: #fff; text-decoration: none; }
}

@layer states {
  .is-disabled { color: #9ca3af; }
}

No IDs, no !important, and the disabled state wins because of where it sits, not because of how heavy its selector is. When a new state is needed next year, it goes in the states layer with a single class.

Platform notes

WordPress and page builders

Themes and builders often use ID-based wrappers and write inline styles for colours and spacing chosen in their settings panels. Set the value in the builder where possible rather than overriding it in CSS. For theme CSS you cannot edit, a child theme stylesheet enqueued after the parent, with selectors matching the parent's weight, is still the most predictable route. More on this in CSS in WordPress themes.

Component frameworks

CSS Modules, scoped styles in Vue or Svelte, and utility-first frameworks all keep specificity low by design, usually at one generated class. Conflicts there tend to come from global stylesheets imported alongside the components, or from the order in which bundled CSS files load. The React and Next.js guide covers load-order issues specific to those builds.

Utility frameworks

Utility classes need to win over component styles, which is why some frameworks offer an "important" mode that adds !important to every utility. Current versions of popular utility frameworks build on cascade layers instead, which achieves the same thing without making the utilities impossible to override later.

Scoping styles so they do not leak

Many specificity fights begin as leaks: a rule written for one area of the site also matches elements elsewhere, and someone raises specificity to stop it. Tighter scoping removes the leak at source.

• One class per component. A class that names the component is scoped by convention.
• The @scope rule. It limits styles to a subtree, and can stop at an inner boundary so a card's styles do not leak into content nested inside it. Browser support has been arriving in stages, so check Can I Use and provide a fallback if you rely on it.
• Build-time scoping. CSS Modules and framework scoped styles rename classes so they cannot collide.
• Shadow DOM. Web components isolate their styles completely, which is powerful but also blocks global theme styles unless you pass them in through custom properties.

Scoping and layers work well together: layers settle which group of styles wins, and scoping makes sure each rule only matches what it was written for.