Markdown to HTML for Gmail & WordPress
You wrote a clean draft in Markdown, pasted it into Gmail or the WordPress editor, and hit send or publish. Then you saw it: literal asterisks wrapping your bold text, pound signs in front of your headings, and square-bracket links that go nowhere. Nothing rendered. Here is why that happens, and the four practical ways to get real formatted output instead.
Why your asterisks show up literally
Markdown is plain text. The symbols you type, like **bold**, ## Heading, and [link](url), are instructions for a Markdown processor to convert into HTML. Gmail, Outlook, and the classic WordPress editor are not Markdown processors. When you paste raw Markdown into them, they treat your asterisks and hashes as ordinary characters and display them verbatim.
To get formatted rich text, you have to run the conversion before the text reaches the email or CMS field, then paste the resulting HTML, not the Markdown. The goal of every workflow below is the same: turn Markdown into HTML, then deliver that HTML as styled rich text rather than as source code.
Four workflows, ranked by use case
1. Browser extension for in-place conversion (best for frequent senders)
The original tool for this is Markdown Here, a browser extension that lets you write Markdown directly in a Gmail or other webmail compose window, then convert the selection to rich text in place with a keyboard shortcut or context-menu click. If you live in your email and send formatted messages all day, this is the lowest-friction option because there is no copy-paste round trip. Note that the original extension has not been actively maintained for years, and the community fork that succeeded it dropped browser-based email support entirely (it now targets the Thunderbird desktop client), so the original may behave inconsistently in newer browsers or webmail. Test it before relying on it for important mail.
2. Online converter with a copy-rich, paste-rich workflow (best for occasional use)
For one-off documents, use a converter that produces HTML and lets you copy rendered output. The reliable pattern is: convert your Markdown to HTML, view the rendered result, select all of the rendered text, copy it, then paste into Gmail or WordPress. Because you copied formatted text rather than the HTML source, the editor receives styled rich text. Our Markdown and HTML converter runs entirely in your browser and shows you both the HTML source and a preview, so you can grab whichever form you need.
3. The browser render-and-select-all trick for Gmail (free, no install, with limits)
You can skip extensions entirely. Render your Markdown in a live preview, select the rendered output with Ctrl+A (Cmd+A on Mac), copy it, and paste into the Gmail compose box. Our live Markdown preview is built for exactly this. It works well for paragraphs, bold, italics, lists, and links.
Be honest with yourself about its limits. When you paste rendered HTML into Gmail, the email field keeps only the formatting it supports. In practice, custom colors and exact heading sizes frequently do not survive, because the styling that produced them gets dropped or normalized. Bold, italic, bullet and numbered lists, and hyperlinks are the formatting that travels reliably. Treat the result as a starting point and fix anything important by hand in the compose window.
4. Zapier or similar automation (best for recurring WordPress publishing)
If you publish to WordPress on a schedule from a Markdown source such as Notion, a Google Doc, or a Git repo, manual conversion gets tedious. An automation platform like Zapier has a built-in "Convert Markdown to HTML" formatter step, and its WordPress "Create Post" action publishes the result through the WordPress REST API. This is overkill for a single email but pays off when the same conversion happens repeatedly. The WordPress block editor does convert Markdown shortcuts as you type, and it can convert a whole pasted document if you paste as plain text (Ctrl+Shift+V, Cmd+Shift+V on Mac), but that path is browser- and clipboard-dependent and often inserts your text as one unformatted block instead, which is why the conversion-first approach still matters.
The email-client compatibility problem nobody mentions
Here is the differentiator most guides skip. HTML email does not render like a web page. Email clients run stripped-down, inconsistent HTML and CSS engines, and two of the biggest, Gmail and Outlook, are especially restrictive.
- Gmail removes
<style>blocks in important cases. Per Gmail's CSS support documentation, Gmail removes external stylesheets and@importrules outright, and it drops an embedded<style>block if it hits a CSS error, exceeds about 8 KB, or the mail is read through a non-Gmail account. The dependable approach is to put your CSS inline on each element using thestyleattribute. - Classic desktop Outlook on Windows renders with Microsoft Word's engine. Outlook 2007 through 2019 and desktop Microsoft 365 use Word to render HTML, which ignores or mangles many modern CSS features like flexbox and grid. (The new Outlook for Windows, plus the Mac, web, and mobile apps, use real browser engines, but the Word-based clients are still in heavy use.) Inline styles on simple elements are the safe baseline.
The practical rule: for email, inline CSS is the only formatting you can count on. A converter that emits a clean HTML body with semantic tags gives you a solid base, but if you need styling to survive across clients, inline it onto the elements rather than relying on a <style> tag or external sheet. This is also why the simple copy-rendered-text method often works better for email than copying raw HTML: the browser hands the email field already-applied inline formatting.
A privacy note: convert client-side
Many online Markdown converters send your text to a server to process it. For a published blog post that is harmless. For an unpublished draft, a confidential proposal, an internal memo, or a client email, it means your content touches a third party's infrastructure before you have decided to share it. Prefer a converter that does the work entirely in your browser so the text never leaves your machine. Both our converter and preview run client-side for this reason. We cover the broader case in our guide on how Markdown flavors differ, which also explains why the same Markdown can render differently depending on the processor behind your converter.
Quick decision guide
- Send formatted email constantly? Try a browser extension for in-place conversion, but verify it still works in your setup.
- Occasional document or one email? Convert to HTML, then copy the rendered output and paste, or use the render-and-select-all trick.
- Recurring WordPress publishing from a Markdown source? Automate the conversion plus a REST API post.
- Need to strip formatting entirely? Use a Markdown to plain text converter to get clean, symbol-free prose.
Whichever route you pick, the core fix never changes: convert Markdown to HTML before it reaches the editor, and for email, lean on inline styling and the formatting you know survives. Do that and the literal asterisks disappear for good.
Frequently Asked Questions
Gmail is not a Markdown processor. When you paste raw Markdown, it treats symbols like ** and ## as plain characters and displays them literally. You must convert the Markdown to HTML first, then paste the rendered, formatted text into the compose window rather than pasting the Markdown source.
When you paste rendered HTML, Gmail keeps only the formatting its editor supports and drops or normalizes the rest. Bold, italics, lists, and links usually survive, but custom colors and exact heading sizes often do not. Fix anything important by hand in the compose box after pasting.
Email clients run limited HTML and CSS engines. Per Gmail's CSS support docs, Gmail removes external stylesheets and @import rules outright and drops embedded