April 13, 2026 ・ Updated: August 18, 2026Markdown Writing

Written and tested by the MD Converter editorial team

Why CSS Doesn't Apply to Markdown HTML — 4 Causes and Fixes

Diagnose CSS that fails on Markdown HTML by checking generated selectors, sanitization, stylesheet paths, cascade order, CSP, and print-only rules.

What you'll learn

The four main reasons CSS doesn't apply to Markdown-converted HTML
How to diagnose each cause with browser devtools
How Markdown maps to HTML (so you can write matching selectors)
Why sanitizers strip style attributes and how to work around them
External CSS path, CORS, and load-order troubleshooting
What to do when only print/PDF looks wrong

You cannot write CSS inside a Markdown file in the usual workflow. Display works in two steps: Markdown → HTML, then the browser applies CSS to that HTML. When styles "don't work," it is usually one of four causes below.

Reason 1: Selectors don't match generated HTML

Converted HTML follows predictable shapes: headings <h1>–<h6>, lists <ul> / <ol> and <li>, code <pre><code>, and so on. If your CSS targets .title or #main but the converter never emits those classes or ids, no rules apply. Open devtools, inspect the live DOM, and rewrite selectors to match actual tags and classes. Selectors like article h1 can work without relying on classes.

Common Markdown → HTML mappings:

Markdown	Generated HTML
`# Heading`	`<h1>Heading</h1>`
`bold`	`<strong>bold</strong>`
`- list item`	`<ul><li>list item</li></ul>`
`code`	`<code>code</code>`
```code block```	`<pre><code>code block</code></pre>`

Reason 2: Inline `style` / `class` sanitized

Blogs, wikis, and portals often strip style, class, or certain tags for XSS prevention. Even if you write <span style="color:red"> in Markdown, a sanitizer removes it and nothing changes. Check the platform's allowed tags list. In a custom pipeline, review DOMPurify (or similar) allowlists.

Reason 3: External CSS path, CORS, load order

With <link rel="stylesheet" href="...">, wrong relative paths after build mean 404s. CSP style-src may block inline or cross-origin styles. If a theme CSS loads later, it can override your rules so it looks like yours "lost." Use the Network tab to confirm CSS returns 200; in Elements, check for struck-through declarations.

Reason 4: Only print/PDF looks wrong

If screen looks fine but print or PDF breaks, @media print or user print styles may differ from screen. That is separate from Markdown content—see Why Markdown PDFs and print look broken.

What to do

Write selectors against the actual post-conversion DOM.
Read what HTML/CSS your tool allows.
When raw CSS is unavailable, use the converter's layout controls or apply a stylesheet to HTML output.

Before leaning on `!important`

When rules still lose, try higher specificity (more specific ancestors) or custom properties tied to your theme. Piling on !important makes maintenance harder. Framework resets or utilities may override Markdown output margins—use Computed in devtools to see the final winning values.

FAQ

My rule shows a strikethrough in devtools

It is being overridden. Find which selector wins in the Elements tab—it's either higher specificity or a stylesheet loaded later.

I wrote `style="color:red"` in Markdown but nothing changed

The platform likely sanitizes inline style attributes by default. Switch to class-based CSS or check what the tool permits.

CSS works locally but breaks after deploy

Check that the CSS file path matches the deployed directory structure. Also confirm that CSP on the production server doesn't block external or inline styles.

The converter does not accept raw CSS. What can I do?

Some converters restrict raw CSS because of sanitization or security policy. Use built-in controls for font size, line height, margins, and content width, or export HTML to a workflow where you can attach a reviewed stylesheet.

Only the PDF looks wrong, not the browser

The PDF goes through @media print rules which differ from screen CSS. See Why Markdown PDFs and print look broken for a full diagnostic guide.

What is the fastest debugging order?

Inspect the generated element, confirm that the expected class or tag exists, check whether the rule appears in Computed styles, and then inspect the winning declaration. If the stylesheet never loads, use Network and CSP messages before changing specificity. Test print preview last, because print rules form a separate cascade.

Change one layer at a time. Adding !important before identifying the winning selector can hide the real source and create a harder maintenance problem.

Markdown to PDF