When two CSS rules target the same element with different values for the same property, something has to settle the tie. That something is the cascade: the set of rules that determine which declaration finally wins on screen.
Understanding the cascade as a whole avoids treating every style conflict as an isolated mystery, when it actually follows a perfectly defined resolution order, step by step.
Definition
The cascade is the algorithm the browser runs to choose, among every CSS declaration that targets the same element and the same property, the one that will actually be applied. It relies on several criteria examined in a precise order.
The criteria, in order
The browser successively examines a rule's origin and importance, the cascade layer it belongs to, its Specificity, and finally, as a last resort, its order of appearance in the code.
/* rule 1, earlier in the file */
p {
color: navy;
}
/* rule 2, later in the same file, same specificity as rule 1 */
p {
color: crimson;
}
/* result: crimson wins, since this rule comes after, with equal specificity */Origin distinguishes the browser's default styles, styles written by the site's author, and preferences imposed by the user. Barring special cases, author styles win over browser styles. The !important declaration flips that balance of power by giving near absolute priority to the rule carrying it, which makes it a tool to use sparingly.
Cascade layers
Cascade layer let rules be grouped inside named blocks whose relative priority is defined explicitly, independent of the order in which the blocks appear in the file. A style placed inside a layer declared as higher priority wins over a style placed inside a lower priority layer, even if the latter has higher specificity or appears later in the code.
| Step | Criterion examined |
|---|---|
| 1 | Origin and importance (!important) |
| 2 | Cascade layer |
| 3 | Selector specificity |
| 4 | Order of appearance in the code |
Why understanding the cascade avoids bad habits
Without this overview, a style that refuses to apply often pushes people to add !important out of reflex, which fixes the symptom without ever addressing the cause. By identifying which stage of the cascade the conflict actually plays out at, the fix becomes precise: adjust specificity, review rule order, or reconsider how layers are organized.
When a style does not apply as expected, walk back through the stages of the cascade in order rather than reaching for !important first: the real cause is almost always in specificity or in rule order.
A full example, step by step
Picture two competing rules: one comes from a third-party component library, the other is written by the project's own team. If both share the same specificity, the one loaded last wins, which explains why the import order of stylesheets in a project genuinely matters and deserves to be documented rather than left to chance. Loading a project's own styles after any third-party library consistently avoids this kind of ambiguity from the start. Our HTML and CSS course walks through this kind of conflict with concrete examples, to help you diagnose a rule that will not apply at a glance.
Frequently asked questions
No, these are two distinct mechanisms. The cascade settles conflicts between competing rules, while inheritance passes a property's value from a parent element down to its children when no rule defines it directly on them.
The order of appearance in the code settles the tie between the two rules: the one declared last wins, which explains why the load order of CSS files can sometimes change a rendered result.
style attribute count in the cascade?Yes, and they sit very high in the priority order, just below !important, which makes them hard to override from a regular external stylesheet.