A style that refuses to apply despite a rule that looks perfectly correct is one of the most frustrating moments in CSS. Nine times out of ten, the cause is not a browser bug but another rule, somewhere else in the stylesheet, winning priority. The temptation is then to add !important to the property in question to force it through.
That fix almost always works, which is exactly the problem: it treats the symptom without ever explaining why the other rule was winning, and it leaves a time bomb for the next person who tries to override that value.
Definition
!important is a flag added at the end of a CSS value that pulls that declaration out of the normal Cascade calculation. A property marked !important beats any other declaration of the same property on the same element, regardless of its Specificity, unless it faces another declaration that is also marked !important and more specific.
.button {
color: blue;
}
.button {
color: red !important; /* this one wins, even written first */
}The syntax is strict: the exclamation mark sits directly against the word important, with no space between them, and a space separates it from the value.
How it reorders priority
Normally the browser picks the winning rule by comparing each selector's specificity, then, if tied, by keeping the last one declared. !important short-circuits that logic: every important declaration is settled among itself first, before normal declarations are even considered.
| Situation | Winner |
|---|---|
| Two normal declarations | The more specific one, otherwise the last one |
| A normal one against an important one | The important one, always |
| Two important ones | The more specific one, otherwise the last one |
That last row is the classic trap: two !important declarations fighting over the same property force a third, even more specific one, just to settle it. That is the start of an escalation nobody really wins.
!important, look for why the other rule is really winning: an overly generic selector, a reversed import order, or a stylesheet loaded after yours. Fixing the cause avoids stacking patches that trip over each other.The rare legitimate cases
The defensible use case stays narrow: overriding a style imposed by third-party code you do not control, a plugin, an embedded widget, or a library that applies inline styles that are hard to target any other way. In that specific context, !important is not a shortcut, it is often the only handle available.
Another accepted use is the deliberately absolute utility class, for instance .hidden { display: none !important; }, whose whole purpose is to never be overridden by accident. There, forced priority is part of the class's contract, not a mistake along the way.
Why it is a last resort, not a habit
A project where !important spreads loses its readability: the stylesheet no longer follows the order it is written in, and fixing one style sometimes changes another, in a spot that seems unrelated, because a forgotten !important was still applying. A well-designed Cascade layer, or simply a better-targeted selector, solves the vast majority of cases where !important looked like the only way out.
Frequently asked questions
!important be cancelled by inline CSS?Not the other way around: an inline style (the style attribute) normally outranks an external stylesheet, but an !important written in an external stylesheet still beats an inline style without !important. Only an inline !important beats a less specific external !important.
!important slow down page rendering?No, its performance cost is zero: the browser computes the cascade the same way regardless. The real cost is human, in time lost figuring out why a value refuses to move despite repeated edits.
!important be banned entirely from a project?No, banning it outright sometimes pushes developers toward artificially complicated selectors just to win on specificity, which is worse. The sound rule is to reserve it for deliberate utilities and third-party overrides, and to rule it out of ordinary feature CSS.