How to convert markdown to html for an email newsletter
- Step 1Paste the newsletter draft or drop the .md — Paste your Markdown or drop the
.mdfile. One file per run; merge sections first with md-merger if your draft is split. - Step 2Use fragment mode for the ESP code editor — Turn Full document OFF to get body-only HTML for pasting into Mailchimp Code view or a custom-HTML block. Keep it ON only for a standalone preview to share for approval.
- Step 3Run the conversion — marked renders the HTML locally and instantly. Nothing is uploaded — important for unsent, embargoed campaign content.
- Step 4Inline the CSS before sending — This is the key step. The HTML here uses semantic tags with no inline styles. Run it through a CSS inliner (or your ESP's template, which applies its own styles) so Outlook and other strict clients render it. Do NOT paste this raw HTML as a finished email.
- Step 5Check links and images — Confirm CTA links became
<a>tags and add UTM tracking params if you need them (the converter won't add tracking). Images keep their originalsrc— host them on a public URL and re-point each<img>. - Step 6Paste into the platform and send a test — Paste the inlined HTML into your ESP, then send a seed/test email and preview across clients. Email rendering varies wildly — always test before the real send.
Newsletter elements and conversion
Verified against marked 14.1.4. 'Email caveat' flags where email clients need extra work the converter does not do.
| Element | Markdown | HTML output | Email caveat |
|---|---|---|---|
| Section heading | ## News | <h2>News</h2> | Inline styles for consistent rendering |
| Paragraph | plain text | <p>…</p> | Inline font/colour for Outlook |
| Bulleted list | - item | <ul><li>item</li></ul> | Inline list styles; some clients restyle |
| CTA link | [Read more](url) | <a href="url">Read more</a> | Add UTM params yourself; style as a button via inlined CSS |
| Image |  | <img src="img.png" alt="alt"> | Use absolute public URLs; set width; expect blocked-by-default |
| Divider | --- | <hr> | Inline styling needed |
| Table | GFM pipe table | <table> (no inline CSS) | Needs inlined borders/widths for email |
Why this is not yet email HTML
What the converter does vs what a sendable email needs — plan the gap into your workflow.
| Email need | Does marked output it? | How to bridge it |
|---|---|---|
| Inlined CSS on elements | No — semantic tags only | Run output through a CSS inliner before sending |
| Table-based layout | No — flow HTML | Use your ESP template or a layout wrapper |
<head> styles respected | Full doc adds a <style> block, but many email clients ignore it | Inline the styles instead |
| Absolute image URLs | No — paths kept verbatim | Host images publicly; re-point src |
| Click tracking / UTM | No | Add params before converting, or let the ESP wrap links |
Tier limits (markdown family)
Per-file limits. Character cap is independent of byte size.
| Plan | Max file size | Max characters | Files per run |
|---|---|---|---|
| Free | 1 MB | 500,000 | 1 |
| Pro | 10 MB | 5,000,000 | 10 |
| Pro + Media | 50 MB | 20,000,000 | 50 |
| Developer | 500 MB | unlimited | unlimited |
Cookbook
Newsletter-draft snippets, the HTML this tool produces, and the email-specific follow-up each one needs.
Intro section converts to clean semantic HTML
A heading plus paragraph plus CTA — the spine of any newsletter — converts to semantic HTML. Remember it has no inline styles yet.
Input: ## This week Three updates you'll want to see. [Read the full post](https://example.com/post) Output (fragment): <h2>This week</h2> <p>Three updates you'll want to see.</p> <p><a href="https://example.com/post">Read the full post</a></p> Next: inline CSS before sending.
List of headlines
A bulleted 'in this issue' list becomes a <ul>. Email clients vary on default list styling, so inline the styles you care about.
Input: - New pricing - Office hours - Hiring update Output: <ul> <li>New pricing</li> <li>Office hours</li> <li>Hiring update</li> </ul>
CTA link — add UTM before converting
The converter does not add tracking. If you track campaign clicks, put the UTM params in the Markdown link so they end up in the href.
Input (UTM added in the Markdown): [Shop now](https://example.com/sale?utm_source=newsletter&utm_medium=email) Output: <a href="https://example.com/sale?utm_source=newsletter&utm_medium=email">Shop now</a> Style it as a button with inlined CSS in the next step.
Image needs a public absolute URL
Email clients can't load relative or local paths. The converter keeps the path verbatim, so host the image and re-point the src after conversion.
Input:  Output: <img src="./img/hero.png" alt="hero"> Fix for email: <img src="https://cdn.example.com/hero.png" alt="hero" width="600"> (Pre-rewrite with md-image-path-rewriter to avoid manual edits.)
Full document mode for sign-off, not for sending
Use Full document ON to produce a readable preview file to circulate for approval — but never paste that whole-page HTML into the ESP as the email.
Full document ON → complete page with built-in <style>:
<!DOCTYPE html> … <style> body{max-width:860px…} </style> …
Good for: emailing a preview for sign-off.
Not good for: the actual campaign HTML — email clients
ignore the <style> block; you must inline CSS instead.Edge cases and what actually happens
Output is not email-ready HTML
Important caveatThis converter emits standard semantic HTML with no inlined CSS and no table-based layout. Email clients — Outlook especially — ignore <style> blocks and need CSS inlined on each element. Sending this raw will render inconsistently. Always run the output through a CSS inliner and your ESP template before the real send.
<style> block in full-document mode is ignored by many clients
By design / email limitationFull-document mode includes a <style> block in the <head>. Gmail (clipped), Outlook, and several mobile clients ignore or strip head styles. Don't rely on it for email; use it only for a browser preview. Inline the CSS for the actual campaign.
Relative image paths won't load in email
Preserved (needs fixing) becomes <img src="./img/x.png">. Email needs absolute, publicly reachable URLs. Host the images and re-point each src, or run md-image-path-rewriter to swap local paths for your CDN base before converting.
No click tracking is added
ExpectedThe converter copies link hrefs verbatim — it does not append UTM parameters or wrap links for tracking. Add UTM params in the Markdown before converting, or let your ESP wrap links with its own tracking on send.
Tables convert but have no email styling
Needs inliningGFM tables become <table> with no inline borders or widths (the built-in <style> won't help in email). For a table that renders in Outlook, inline border/cellpadding/width attributes and styles after conversion.
Footnotes break
Not supportedNewsletters with footnote-style references ([^1]) will produce broken links — core marked has no footnote support. Convert footnotes to inline links before converting.
Raw HTML passes through unsanitized
Not sanitizedAny HTML in the draft (buttons, custom blocks, tracking pixels) passes through verbatim. Useful if you hand-wrote an email-safe button table, but be deliberate — your ESP may sanitize on import, and inline <script> will not work in email at all.
Emoji shortcodes stay literal
Not supportedSubject-line-style shortcodes like :sparkles: are not expanded — they appear as text. Unicode emoji you typed directly survive. To strip emoji for a more formal newsletter, use md-emoji-remover.
Front matter leaks into the email body
Remove firstIf your draft has YAML front matter (subject, preheader, etc.), marked does not strip it — it appears in the HTML. Remove the --- block before converting so campaign metadata doesn't show up in the email body.
Draft exceeds the free character cap
400 rejectedOver 500,000 characters / 1 MB and the Free plan rejects the file before conversion. Newsletters are rarely this large; a digest that concatenates many articles could be. Pro raises it to 5,000,000 / 10 MB.
Frequently asked questions
Can I paste this HTML straight into my email and send it?
No — and this is the most important caveat. The output is standard semantic HTML with no inlined CSS and no table-based layout. Email clients (especially Outlook) ignore <style> blocks and render inconsistently. Convert here, then run the HTML through a CSS inliner and your ESP template before sending, and always send a test first.
Should I use full-document or fragment mode for my ESP?
Fragment — turn Full document OFF — for pasting into Mailchimp's Code view or a custom-HTML content block. Use full-document mode only to produce a standalone preview file for internal sign-off, not for the actual campaign.
Why doesn't the <style> block from full-document mode work in email?
Many email clients (Outlook, parts of Gmail and mobile) ignore or strip <style> blocks in the <head>. That's why email HTML inlines CSS onto each element. The full-document <style> is fine for a browser preview but won't style the email — inline the CSS instead.
Will my images show up in the email?
Only after you host them publicly and use absolute URLs. The converter keeps image paths verbatim, so relative or local paths won't load in email. Re-point each <img src> to a public URL, or pre-rewrite paths with md-image-path-rewriter.
Does it add UTM tracking to my links?
No. Link hrefs are copied verbatim. If you track campaigns, add UTM parameters in the Markdown links before converting, or rely on your ESP to wrap links with its own click tracking on send.
Are GFM tables usable in email?
They convert to <table> elements, but with no inline borders or widths — and the built-in <style> won't apply in email. For a table that renders in Outlook, inline the table attributes and styles after conversion.
Is my unsent campaign draft uploaded anywhere?
No. Conversion runs in your browser via marked, so an embargoed or unsent draft never leaves your machine. Only an anonymous processed-file counter is recorded for dashboard stats, never the content.
Why do my footnotes break?
Core marked has no footnote support, so [^1] becomes a broken reference link. Convert footnotes to inline links before converting your newsletter draft.
What happens to front matter in my draft?
marked does not strip YAML front matter, so a --- block at the top leaks into the HTML body. Remove it before converting so campaign metadata (subject, preheader) doesn't appear in the email.
Can I run this in a content-ops pipeline?
Yes — the API exposes md-to-html via GET /api/v1/tools/md-to-html for the option schema, and the engine produces stable, dependency-free HTML that's easy to feed into a CSS-inlining step. A typical flow: draft in Markdown → convert → inline CSS → ESP import.
How large a draft can I convert?
Free: 1 MB / 500,000 characters per file. Pro: 10 MB / 5,000,000. Pro + Media: 50 MB / 20,000,000. Developer: 500 MB / unlimited. The character cap is separate from the byte size.
What file name does the download use?
The output keeps your input's base name with a .html extension — issue-42.md becomes issue-42.html. .markdown, .mdx, and .txt inputs are handled the same way. For ESP pasting you usually copy the HTML rather than download it.
Privacy first
All Markdown processing runs locally in your browser using JavaScript. No file is ever uploaded to JAD Apps servers — only metadata counters are saved for signed-in dashboard stats.