Inline Style

Why It Matters

Inline styles are the reason a perfectly good rule in your stylesheet does nothing. If a heading refuses to change colour and the styles panel shows the rule struck through, look at the element itself: a style attribute beats a class every time. They are also expensive to maintain — the same declaration repeated across forty elements is forty edits, and they are re-sent with the HTML on every request rather than cached as part of a stylesheet. There is one place they earn their keep: a small block of critical CSS or a value only known at runtime, such as a progress bar width being set by script.

How It Works

The parser reads the style attribute and attaches its declarations to that element as its own style block, handled by the cascade at a level above all selector-based rules. Machine-generated pages lean on this heavily — an exported document or an AI-written page often carries a style attribute on every paragraph, which is legal but leaves nothing to target from a stylesheet. When a script runs element.style.display = "none", it writes an inline style, and that is why the element stays hidden even after you fix the CSS class. The way out is usually to remove the attribute rather than fight it: delete the style attribute and let a class take over, or in a script set the property back to an empty string to hand control back to the stylesheet.

Real-World Example

Common Mistakes

• ✕Writing a selector or braces inside the attribute — style="p { color: red }" is invalid, because the attribute takes declarations only
• ✕Trying to put a hover or a media query inline — neither works without a selector, so those belong in a stylesheet
• ✕Adding !important to a stylesheet rule to beat an inline style — it works, but the real fix is usually to remove the style attribute that should not have been there

Related Terms