Everyday Utilities Free · No signup · Private · Instant results

CSS to Inline Styles

Convert CSS class rules to inline styles — useful for HTML email templates.

HTML Input

CSS Input

About the CSS to Inline Styles

The CSS to Inline Style Converter on HT99 Tools takes a snippet of HTML with class= attributes and a CSS stylesheet of class rules, and rewrites the HTML so that each element's class becomes a style= attribute containing the matching declarations. The output is HTML that no longer needs an external stylesheet to render — every rule is inlined onto the element it applies to.

This is the workflow that HTML email demands. Gmail, Outlook, and Yahoo Mail strip <style> blocks from the <head> of incoming emails (Outlook for Windows even strips them from the <body>), so the only reliable way to style an email is to inline every declaration onto the element it should affect. The same approach is useful for embedded widgets that must render correctly when injected into a host page whose stylesheet you do not control.

The converter parses .class { prop: value; } rules from the CSS input, builds a lookup table from class name to declaration block, walks the HTML with a real DOM parser, and for each element with a class attribute, looks up the matching declarations and writes them to a style attribute. Multiple classes on the same element are concatenated in order.

How It Works

The CSS parser uses the regex /\.([a-zA-Z0-9_-]+)\s*\{([^}]*)\}/g to extract class selectors and their declaration bodies. The regex handles single-class selectors only — it does not parse descendant selectors (.parent .child), pseudo-classes (:hover), media queries (@media), or specificity calculations. Those constructs are not inlinable in the general case — an :hover declaration has no DOM element to attach to — and email clients do not support them anyway.

The HTML is parsed with new DOMParser().parseFromString(html, 'text/html'), which uses the browser's native HTML parser. This is important because it correctly handles the same edge cases the browser does: malformed nesting, void elements (<br>, <img>), self-closing tags, and entity expansion. Regex-based HTML parsing cannot reliably do this.

For each element with a class attribute, the converter splits the class list on whitespace, looks up each class in the table, and joins the matching declaration bodies into a single style attribute separated by semicolons. The original class attribute is left in place so that any unmatched classes are still observable.

Worked Examples

The default input is a card component with three classes: card, title, and body. The CSS defines each of them with a few declarations. After conversion, the HTML becomes:

<div class="card" style="padding:1rem;border:1px solid #ddd;border-radius:8px">
  <h1 class="title" style="font-size:1.5rem;color:#047857">Welcome</h1>
  <p class="body" style="color:#333;line-height:1.5">Hello there.</p>
</div>

Each element now carries its styles inline and renders correctly even when the <style> block is stripped by an email client.

If an element has multiple classes (class="card highlight"), the declarations are concatenated in the order the classes appear. If a class is not found in the CSS input, it is silently skipped — the class attribute is preserved, but no style is added for it.

If two rules apply to the same class — say the CSS has both .btn { color: red } and later .btn { color: blue } — the last one wins (consistent with the CSS cascade for same-specificity rules). The tool reports how many rules were parsed and how many were actually applied.

When to Use This Tool

Producing HTML email templates that render correctly in Gmail, Outlook, and Yahoo Mail.
Building a widget or embed that must render correctly in a host page whose stylesheet is unknown.
Converting a static-site page to a single-file archive (no external CSS dependency).
Migrating a CSS-class-based design to a inline-style based one for a one-off render.
Demonstrating how a class-based stylesheet translates to inline styles for a tutorial.
Sanitising CMS-generated HTML by removing class dependencies before publishing.
Producing AMP pages (which forbid external stylesheets in some configurations).

Limitations & Disclaimer

The tool parses single-class selectors only (.classname { ... }). It does not handle element selectors (body), ID selectors (#main), attribute selectors ([type=text]), descendant selectors (.parent .child), pseudo-classes (:hover, :focus), pseudo-elements (::before), or @media queries. It does not compute specificity or apply cascade rules beyond source order. The output preserves the original class attribute alongside the new style attribute — you may want to strip the class attribute manually for production email templates. See our disclaimer for full terms.

Frequently Asked Questions

Why do I need to inline CSS for HTML email?

Because most email clients strip <code><style></code> blocks from the <code><head></code> (Gmail) or even from the <code><body></code> (Outlook for Windows). The only reliable way to apply styles to an email is to inline them as <code>style=</code> attributes on each element. Tools like MJML, Premailer, and this converter automate that step.

What happens to descendant selectors like .parent .child?

They are not converted. The tool only parses single-class selectors (<code>.classname</code>), because descendant selectors require a contextual lookup at render time and cannot be statically inlined. If your CSS relies on descendant selectors, refactor it to use specific class names (e.g. <code>.child-inside-parent</code>) before inlining.

Does the tool handle pseudo-classes like :hover?

No. <code>:hover</code>, <code>:focus</code>, <code>:active</code>, and other pseudo-classes cannot be inlined because they describe a state, not an element. Email clients generally do not support pseudo-classes anyway. For interactive states in email, use the limited <code><style></code> support in <code><head></code> (Apple Mail, some Gmail configurations) and accept that those styles will not appear in Outlook.

What about @media queries?

Same answer: they cannot be inlined because they describe a viewport state, not an element. The tool ignores <code>@media</code> blocks. For responsive email, the state of the art is to use a hybrid of inlined styles for desktop defaults and a small <code><style></code> block in <code><head></code> for media-query overrides — accepting that clients which strip the head will show the desktop version.

What happens if a class is in the HTML but not the CSS?

The class is left in place but no <code>style</code> is added for it. The converter reports how many classes were matched so you can spot any that you forgot to define. If you want to remove unmatched classes from the HTML entirely, do that manually after conversion.

Is my HTML uploaded anywhere?

No. Parsing and inlining run entirely in the browser via the native DOMParser. Your HTML and CSS never leave the device.

Last updated: September 9, 2026 · Author: HT99 Tools Editorial Team