One of the most underutilized tools in the fight against !important abuse is simply rethinking the order in which your CSS rules are declared. Because when specificity is equal, source order is the tiebreaker — the rule that appears later wins.
This means that in many cases, moving a rule further down the stylesheet is all you need:
/* Declared first */
.button {
color: blue;
}
/* Declared later — wins due to source order */
.button {
color: red;
}It sounds almost too simple, but a surprising number of !important declarations exist solely because a rule was defined in the wrong place. Structuring your stylesheets with a clear, intentional order — resets first, then base styles, then components, then utilities — can eliminate whole categories of cascade conflicts before they arise.
This is also one of the reasons methodologies like ITCSS (Inverted Triangle CSS) exist. Rather than adding specificity or overriding with !important, the philosophy is to write styles in order of increasing specificity and scope, so that later rules naturally take precedence without fighting the cascade.
When specificity is equal between two rules, CSS falls back to source order — the declaration that appears later in the stylesheet wins. This is easy to miss, particularly in larger codebases where styles are distributed across multiple files. If a broad, generic rule keeps winning out over a more targeted one despite matching specificity, the culprit is often load order. Before reaching for a specificity fix, check whether the generic rule is simply being loaded after yours. Reordering the stylesheets may be all it takes.
This is also why stylesheet architecture is worth thinking about early. A well-established convention is to layer styles from general to specific: resets and base styles first, then layout, then components, then utility classes. That ordering tends to prevent a lot of cascade conflicts before they start.
When using !important does make sense
Despite its reputation, !important has genuinely legitimate use cases. Chris explored this in detail previously, and the comments are well worth reading alongside the article.
Utility classes are the most common and defensible scenario. Classes like .visually-hidden are designed to do one specific thing, unconditionally. You don't want a more-specific selector silently overriding them somewhere further down the page. The same logic applies to state classes like .disabled or foundational UI patterns like .button.
.visually-hidden {
position: absolute !important;
width: 1px !important;
height: 1px !important;
overflow: hidden !important;
clip-path: inset(50%) !important;
}Third-party overrides are another practical case. When you're working with a stylesheet you can't edit, or fighting inline styles injected by JavaScript, !important may be the only practical lever available.
From an accessibility standpoint, !important is essentially indispensable for user stylesheets. Because user stylesheets apply across all websites and there's no way to guarantee selector specificity will always be high enough, !important is the only reliable mechanism for ensuring user-defined styles take precedence.
A clear example of this is honoring user preferences for reduced motion:
@media screen and (prefers-reduced-motion: reduce) {
* {
animation-duration: 0.001ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.001ms !important;
}
}Wrapping up
The difference between good and bad uses of !important comes down to intent. Are you reaching for it because you understand the cascade and have made a deliberate decision that this declaration should always apply? Or is it a quick fix to paper over a specificity problem you haven't fully diagnosed? The latter approach compounds over time — and usually bites back.
Further reading
- Specifics on CSS Specificity by Chris Coyier
- Tackling CSS Specificity by Emma Bostian
- Cascade Layers Guide by Miriam Suzanne
- When Using !important is The Right Choice by Chris Coyier
Alternatives to the !important Keyword originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.