April 13, 2026

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

Four reasons CSS doesn't apply to Markdown-converted HTML—selector mismatch, sanitizer, path/CORS failures, print-only issues—and how to diagnose each with browser devtools.

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.
In this app, use layout settings for fonts, margins, and line height within a safe range.

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.

How do I customize styles in this app?

Use layout settings to adjust font size, line height, margins, and max width. Raw CSS editing is restricted for security reasons, but layout settings cover most common style needs.

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.

ToolMarkdown to HTML (md to html)Preview .md in the browser, adjust layout, and download HTML.Open tool