Cascade Inspector in DevTools

When a style you expect doesn't show up, the fastest way to find out why is almost never to re-read your stylesheet from top to bottom — it's to open DevTools and ask the browser directly. Every modern browser's Elements panel gives you two complementary views onto an element's styles: the Styles panel, which shows every rule the browser matched, and the Computed panel, which shows the single final value the browser settled on for each property. Learning to move fluidly between the two is one of the highest-leverage debugging skills in CSS.

The Styles panel: every rule that matched

Select an element with the element picker (the cursor icon, or Ctrl/Cmd+Shift+C) and the Styles panel lists every CSS rule whose selector matches that element, in cascade order — the rule that wins appears first, with rules it beats further down. Rules (or individual declarations) that lost the cascade are shown with a strikethrough, so you can see at a glance exactly which declaration is overriding which. This is the cascade made visible: instead of mentally recomputing specificity and source order (see The Cascade and Specificity), you can just read it off the panel.

CSS

/* styles.css */
.card {
  color: #333;
}

.card.featured {
  color: rebeccapurple;
}

#promo .card {
  color: crimson;
}

/* Selecting a <div class="card featured" id="promo"> element */
/* shows all three rules in the Styles panel: */
/*
  #promo .card          { color: crimson; }        <- winner (ID + descendant)
  .card.featured        { color: rebeccapurple; }  <- strikethrough, loses
  .card                 { color: #333; }           <- strikethrough, loses
*/

Each rule in the panel is also annotated with where it came from — the source file and line number — so you can jump straight to the offending stylesheet with a click. If a declaration is crossed out because a later rule of equal specificity simply appears later in the source, that's your cue that source order, not specificity, decided the winner.

The Computed panel: the final answer

The Styles panel is excellent for understanding why, but it forces you to mentally resolve shorthand properties, inherited values, and browser defaults yourself. The Computed panel skips all of that: for every CSS property on the selected element, it shows the single resolved value the browser is actually using to paint the pixel — after the cascade, after inheritance, after the browser's default stylesheet has been applied.

This matters because a property can end up with a value you never wrote explicitly. A display: flex container's children get a computed flex-basis even if no rule sets it; a deeply nested element's computed color might come from a rule three ancestors up. Chrome and Firefox's Computed tabs both let you expand a property to see which rule contributed it, effectively bridging back to the Styles view when you need the "why" after all.

Panel	Shows	Best for
Styles	Every matching rule, winners and losers, with source location	Understanding why a value won or lost the cascade
Computed	The single final resolved value per property	Quickly checking what value is actually being used

Rule of thumb

Reach for Computed when you just want to know the end result ("what's this element's actual width right now?"). Reach for Styles when the result is wrong and you need to find the specific rule to blame — usually a higher-specificity selector or a later, equally-specific rule elsewhere in the cascade.

A worked debugging session

Select the misbehaving element with the element picker.
Open Computed first — confirm the property genuinely has the "wrong" value (sometimes what looks wrong is actually correct, and the bug is elsewhere).
Switch to Styles — scan top to bottom for the property in question; the first non-strikethrough declaration you see for it is the winner.
If the winner is unexpected, check its specificity and source order against the rule you intended to win — that comparison is the actual bug.
Toggle checkboxes next to declarations in Styles to test hypotheses live, without editing your source files.

Note

Both panels are live — toggling a declaration off, editing a value, or adding a new declaration in the Styles panel updates the page immediately. This makes DevTools a genuine scratchpad for testing cascade fixes before you touch your actual CSS file.