Every team that’s maintained a CSS codebase past a certain size has hit the same wall: a component’s styles get overridden by something else, so someone bumps specificity with an extra class, or reaches for !important. Six months later, the codebase has a dozen !important declarations and nobody remembers which one actually wins in which context. Cascade Layers, standardized in CSS and supported in all major browsers since 2023, solve this at the root by letting you control precedence through explicit ordering instead of specificity arithmetic.

This guide covers what cascade layers actually change about how the cascade works, how to structure layers in a real project (resets, third-party frameworks, components, utilities, and overrides), and the pitfalls that catch people who adopt them without adjusting existing habits.

How the cascade works without layers

Without layers, the browser decides which of several conflicting rules wins using, in order: origin and importance (author vs. user-agent styles, !important flips the normal order), specificity (ID beats class beats element), and finally source order (later rules win ties). Specificity is the part that causes the most pain, because it’s not really about intent — a rule written with more selectors wins even if it was defined earlier and meant to be a low-priority default.

/* This rule has specificity (0,1,0) — one class */
.button {
  background: blue;
}

/* This rule has specificity (0,2,0) — it wins, even if it appears first in the file */
.card .button {
  background: gray;
}

Multiply that by a real design system, a component library, some third-party CSS, and utility classes, and you get selectors engineered purely to win fights rather than to describe what they style.

What @layer actually changes

Cascade layers add a new, higher-priority step to conflict resolution: layer order beats specificity. If two rules are in different layers, the layer declared later wins — regardless of how specific either selector is. Specificity only matters for breaking ties within the same layer (or between unlayered rules, which implicitly form the highest-priority “layer”).

@layer reset, base, components, utilities;

@layer reset {
  * { margin: 0; padding: 0; box-sizing: border-box; }
}

@layer components {
  .card .button { background: gray; } /* higher specificity, but lower layer */
}

@layer utilities {
  .button { background: blue; } /* wins: utilities layer comes after components */
}

Note the first line: @layer reset, base, components, utilities; declares the layer order up front, before any of the layers have content. This matters because layer order is determined by the position of each layer’s first mention in the stylesheet — declaring the full order early means you can define each layer’s rules anywhere afterward (even in separate files) without accidentally changing precedence.

A practical layer structure for a real project

Most teams converge on some version of this five-layer structure:

@layer reset, vendor, base, components, utilities, overrides;

@import url("normalize.css") layer(reset);
@import url("bootstrap.min.css") layer(vendor);

@layer base {
  body { font-family: system-ui, sans-serif; color: #1a1a1a; }
  a { color: currentColor; }
}

@layer components {
  .card { padding: 1.5rem; border-radius: 0.5rem; }
  .button { padding: 0.5rem 1rem; border-radius: 0.25rem; }
}

@layer utilities {
  .text-center { text-align: center; }
  .mt-4 { margin-top: 1rem; }
}

• reset — normalize/reset styles, always lowest priority so nothing has to fight them.
• vendor — third-party CSS (a component library, Bootstrap, a design system package) that you don’t control but need to override without specificity hacks.
• base — global element defaults (typography, links, form controls).
• components — your own reusable component styles.
• utilities — single-purpose helper classes (margin, text alignment, display) that should generally win over component defaults.
• overrides (optional) — a deliberate escape hatch for genuinely exceptional cases, used sparingly.

The key benefit over the old approach: importing a third-party library into the vendor layer means your own components or utilities rules automatically outrank it, with zero specificity gymnastics or !important, because layer order alone decides the winner.

Layering third-party and vendor CSS

The @import ... layer(name) syntax is what makes cascade layers practical for real-world dependency management. You can pull in an entire external stylesheet — one you can’t edit — and place it precisely where you want it in your precedence order:

@import url("https://cdn.example.com/design-system.css") layer(vendor);

If that design system’s CSS uses aggressive specificity internally (nested selectors, IDs, whatever), it doesn’t matter: because the whole stylesheet lives in the vendor layer, anything you write afterward in components or utilities wins automatically. This is the single biggest practical win of cascade layers — it ends the arms race with vendor CSS specificity.

Unlayered CSS still wins by default

A crucial and frequently misunderstood rule: any CSS not inside a named layer is treated as belonging to an implicit layer that comes after all named layers, meaning it has the highest priority of all. This is a deliberate design decision so that adding @layer to part of your codebase doesn’t retroactively make unlayered legacy CSS lose fights it used to win.

@layer base {
  .button { background: blue; }
}

/* unlayered — this wins regardless of specificity or where it appears */
.button {
  background: red;
}

In practice, this means a half-migrated codebase (some CSS in layers, some not) can produce confusing results: legacy unlayered rules will keep overriding your carefully layered ones. If you’re adopting layers incrementally, plan to move all author CSS into layers together, or keep the unlayered portion intentionally small and understood as “always wins.”

Nesting layers

Layers can be nested, which is useful for grouping related sub-concerns without flattening everything into one big layer:

@layer components {
  @layer buttons, cards, forms;

  @layer buttons {
    .button { padding: 0.5rem 1rem; }
  }

  @layer cards {
    .card { padding: 1.5rem; }
  }
}

Nested layer names are scoped to their parent, so components.buttons and, say, a hypothetical utilities.buttons layer wouldn’t collide. This is mostly useful in larger design systems where a single flat list of layers becomes hard to reason about.

Common pitfalls

A few mistakes come up repeatedly when teams first adopt cascade layers:

• Forgetting the upfront layer order declaration. If you don’t declare @layer reset, base, components, utilities; before any layer content, order gets determined by first-appearance instead, which is fragile across split files and easy to get wrong as the codebase grows.
• Assuming layers replace specificity entirely. Specificity still matters within a layer. Two conflicting rules in the same layer are still resolved by specificity, then source order — layers don’t eliminate the need for sane selector discipline inside a layer.
• Mixing layered and unlayered CSS without a plan. As shown above, unlayered CSS always wins. Adopting layers piecemeal without accounting for this leads to “why isn’t my layer rule applying” confusion.
• !important inside layers reverses the order. Layers with !important declarations are prioritized in the reverse of normal layer order — an !important rule in an earlier layer beats an !important rule in a later layer. This is intentional (so a low-level reset layer can force truly non-negotiable rules) but is exactly the kind of behavior that surprises people debugging a real conflict.

Browser support and fallback strategy

Cascade layers have been supported in Chrome, Firefox, and Safari since early 2022–2023, so for most production audiences they’re safe to use directly. For projects that still need to support older browsers, the safest fallback is graceful degradation: browsers that don’t understand @layer simply ignore the at-rule and layer order, falling back to normal specificity-based cascade resolution for the same rules. This means you should still write reasonably sane specificity inside each layer as a baseline, rather than relying on layers as the sole mechanism keeping your CSS correct.

Conclusion

Cascade layers don’t add new visual capabilities to CSS — they add a missing piece of control: explicit, declarative precedence that doesn’t depend on selector cleverness. For a codebase with resets, vendor CSS, component styles, and utility classes all competing for the same elements, structuring those into layers turns implicit specificity battles into an explicit, readable order declared once at the top of your stylesheet. The upfront investment is small — one line declaring layer order, and moving existing CSS into the right buckets — and it pays for itself the first time you’d otherwise have reached for another !important.