Detailed explanation
In CSS, !important marks an individual declaration as important; it does not make the entire rule important or increase the selector’s specificity. For example, .text { color: black !important; } beats #header .text { color: red; } when both target the same element in ordinary author styles. Although the second selector is more specific, importance is considered before specificity. The element therefore renders black text. This distinction matters because describing !important as “maximum specificity” gives an inaccurate picture of the cascade.
Under the hood, the cascade evaluates factors including origin, importance, cascade layer, specificity, and source order. An important author declaration beats a normal author declaration, including a normal inline style. However, !important is not an absolute guarantee of victory. If two important declarations compete within the same origin and layer, specificity can decide the winner; when other factors tie, the later declaration wins. Important user styles outrank important author styles, allowing users to enforce accessibility preferences. Active CSS transitions can also take precedence over important declarations.
Cascade layers introduce another useful detail: importance reverses their priority. For normal author declarations, later layers outrank earlier layers, and unlayered rules outrank layered rules. For important author declarations, earlier layers outrank later ones, and layered important declarations outrank unlayered important declarations. These rules show why debugging requires examining the full cascade rather than merely counting classes and IDs. In an interview, explain the basic example first, then mention these boundaries instead of claiming that nothing can override !important.
It should generally be avoided because routine use bypasses the intended styling hierarchy and makes components harder to customise. Developers often respond by adding more important declarations, creating competing overrides that become difficult to trace and maintain. Prefer removing conflicting rules, using predictable class selectors, managing source order, or organising styles into cascade layers. Still, !important is a legitimate tool for narrowly scoped overrides, such as enforcing a utility or overriding a third-party normal inline style that cannot be changed. Use it deliberately, keep its scope small, and document the reason.
Key points to remember
- !important applies to one declaration, not an entire rule or selector.
- Importance is evaluated before specificity, so important author styles beat normal author styles.
- Competing important declarations still follow cascade rules; specificity alone is not always decisive.
- Frequent use makes overrides, component customisation, and debugging harder.
- Prefer a predictable cascade; reserve !important for justified, narrowly scoped exceptions.
Common mistakes candidates make
- Saying !important increases specificity or always wins against every possible style.
- Adding !important before inspecting the winning declaration, origin, and cascade layer in DevTools.
- Treating it as either a default fix for conflicts or something that must never be used.
Likely follow-up questions
What happens when both declarations use !important?
First compare their origin and cascade-layer priority. Within the same origin and layer, the more specific selector wins; if all other relevant factors tie, source order decides.
Can !important override inline styles?
An important author stylesheet declaration overrides a normal inline declaration. An important inline declaration beats other important author declarations, but higher-priority sources such as important user styles can still override it.
How would you remove unnecessary !important declarations?
Use DevTools to identify the competing declarations and why each wins or loses. Then simplify selectors, remove obsolete conflicts, or establish explicit layer priorities, checking affected components and states after each change.
Interview tip: Explain the supplied black-versus-red example, clarify that importance is not specificity, and finish with the maintenance cost and one justified exception.