Paste your full HTML email including <style> tags — CSS will be inlined automatically.
Ready to inline
Paste HTML with <style> tags and click Inline CSS// convert style blocks into inline css for email clients
Convert HTML email style blocks into inline CSS automatically. Improve email client compatibility with Gmail, Outlook, and Apple Mail for free.
Paste your full HTML email including <style> tags — CSS will be inlined automatically.
Ready to inline
Paste HTML with <style> tags and click Inline CSSInclude the full HTML with <style> blocks at the top of your email template.
Decide whether to preserve @media queries for responsive email and whether to minify output.
Click Inline CSS, then copy the result or download as an .html file ready to send.
CSS inlining moves styles from <style> blocks directly into each HTML element's style="" attribute. Most email clients — especially Outlook and Gmail — strip or ignore external and internal stylesheets, so inline styles are the only reliable way to control how your email looks.
Gmail removes <style> blocks from emails to prevent style leakage into its own UI. The only way to guarantee styling in Gmail is to use inline style="" attributes on every element. This tool does that conversion automatically.
Yes — with the "Preserve @media queries" option enabled (default), any responsive media queries in your <style> block are kept in a single <style> tag in the <head>. This ensures mobile-responsive layouts still work in clients that support them.
The tool applies CSS exactly as written, including shorthand properties like margin: 10px 20px or border: 1px solid #ccc. For maximum Outlook compatibility, using longhand properties is recommended.
Declarations marked with !important override any existing inline styles on the element, just as they would in a browser. The !important keyword itself is removed from the output since it has no effect in inline styles.
The processing happens server-side via a lightweight PHP API on JLV DevTools servers. Your HTML is processed in memory and never stored or logged. No sign-up or account is required.
Absolutely. Templates from Mailchimp, SendGrid, Campaign Monitor, and other email service providers often include <style> blocks. Paste the exported HTML here to inline those styles before uploading back to your ESP.
Yes — the tool handles common selector patterns including element, class, ID, descendant (A B), and child (A > B) selectors. Complex pseudo-class selectors like :hover are skipped since they cannot be inlined meaningfully.
Yes. Rules are applied in specificity order, so a class selector (.button) correctly overrides an element selector (a). Existing inline styles on elements are also respected and only overridden by !important rules in the stylesheet.
Inline CSS for Email is a browser-based tool that converts HTML email templates with embedded <style> blocks into fully inlined HTML — where every CSS property is written directly into the style="" attribute of each element. This transformation is essential for email development because the majority of email clients either partially or entirely strip external and embedded stylesheets.
Unlike web browsers, email clients are not standard rendering environments. Gmail, Outlook, Yahoo Mail, and other clients implement CSS support in wildly inconsistent ways. The safest, most universally supported method is to attach styles directly to each HTML element using inline attributes.
💡 Looking for premium HTML email templates and UI kits? MonsterONE offers unlimited downloads of email templates, HTML themes, and design assets — worth checking out.
The root cause of email styling challenges is that email clients render HTML using their own proprietary engines, not standard browser engines like WebKit or Blink. Outlook 2007–2021 on Windows, for example, uses Microsoft Word's rendering engine — a layout engine designed for word processing documents, not web content. This engine has almost no support for CSS beyond the most basic properties.
Gmail strips the entire <head> section from emails in its web interface, including any <style> blocks. The Gmail Android app has historically been one of the most restrictive clients in terms of CSS support. Yahoo Mail applies its own styles to emails and removes conflicting class-based styles. Because of these behaviors, CSS that works perfectly in a browser may produce a completely broken layout in an email client.
The solution adopted by the email development industry is CSS inlining: converting each CSS rule into a corresponding inline style attribute. Since inline styles are part of the HTML element itself, they cannot be stripped by email clients without breaking the fundamental structure of the document.
The inlining process involves several steps. First, the tool extracts all <style> blocks from your HTML and parses their CSS. Each CSS rule is broken into its selector and its set of property-value declarations.
Next, the tool analyzes the HTML document using a DOM parser and evaluates every element against every CSS selector. For each matching element, the corresponding CSS properties are merged into the element's inline style attribute. When multiple rules apply to the same element, they are applied in order of CSS specificity — ID selectors win over class selectors, which win over element selectors — mimicking how a real browser would compute styles.
Existing inline styles are respected and preserved. A rule in a stylesheet will not override a style already written inline on the element, unless the rule uses !important. This means you can always pin a specific value on any element by writing it inline in the source HTML.
Finally, the <style> blocks are removed from the output HTML (since their rules have been inlined), and — if the option is enabled — any @media queries found in those blocks are collected into a single <style> tag in the <head>. These queries cannot be inlined and are preserved for email clients that do support them (such as Apple Mail and some versions of the Gmail app on iOS).
CSS specificity determines which rule wins when multiple rules target the same element and property. The standard specificity hierarchy is: inline styles > ID selectors > class selectors > element selectors. This tool respects that hierarchy during the inlining process by sorting rules by their specificity score before applying them to the DOM.
For example, if your stylesheet contains both p { color: black; } and .highlight { color: orange; }, an element like <p class="highlight"> will receive color: orange because the class selector has higher specificity than the element selector.
Modern email development often uses @media queries to create responsive email layouts — switching from multi-column to single-column on small screens, adjusting font sizes, or hiding certain elements on mobile. These queries cannot be inlined because they define conditional rules that depend on the viewport size, not properties of individual elements.
The "Preserve @media queries" option (enabled by default) collects all @media blocks from your stylesheets and places them into a single <style> tag in the document <head>. Email clients that support @media queries — including Apple Mail, Outlook.com, and iOS Mail — will then apply these responsive rules on top of the inlined base styles.
Clients that strip the <head> (like Gmail web) will ignore these queries and fall back to the inlined styles, which serve as a solid baseline. This progressive enhancement approach is standard practice in professional email development.
To get the best results from CSS inlining, keep the following practices in mind when authoring email templates. Use table-based layouts rather than CSS flexbox or grid — Outlook's Word rendering engine has no support for these modern layout models. Write styles in your <style> block as you normally would, then run the inliner before sending or uploading to your ESP.
Use shorthand properties carefully. While most clients handle shorthands like margin: 10px 20px fine, some older Outlook versions behave more reliably with longhand properties (margin-top: 10px; margin-right: 20px; etc.). For maximum compatibility, prefer longhand properties in email stylesheets.
Avoid CSS properties that have poor email client support regardless of inlining: CSS transitions, animations, flexbox, grid, CSS custom properties (variables), and most CSS3 effects. Stick to the core visual properties — color, background, font, border, margin, padding, width, height — which are supported across all major clients.
Most email service providers (ESPs) like Mailchimp, SendGrid, HubSpot, and Klaviyo have built-in CSS inliners. However, these inliners run when you send the campaign, and you cannot inspect the final inlined HTML before sending. Using this tool locally lets you preview and validate the inlined output before uploading your template.
Many developers use this workflow: write the template with a <style> block for readability, run it through the inliner, inspect the result in an email preview tool, then upload the inlined version to the ESP. This gives full visibility into exactly what gets sent to subscribers.
The tool also preserves @keyframes and @font-face blocks, which — like @media queries — cannot be inlined. These are collected alongside @media blocks and kept in a <style> tag in the <head>. @font-face support in email is limited but growing; Apple Mail, Outlook.com, and iOS Mail all support custom web fonts via @font-face. Gmail does not. Using @font-face with a robust font stack fallback ensures that unsupported clients still render readable text.