Markdown-to-HTML in the publishing path
Markdown-to-HTML is the export side of the Markdown ecosystem. You write content in Markdown — readable, version-controllable, easy to diff — and at some point it has to render as HTML for a browser, an email, a CMS body field, or a web component. The conversion is so common that most publishing platforms have it baked in: GitHub renders Markdown READMEs as HTML, Substack renders posts as HTML, Notion exports as HTML, every static site generator builds HTML out of Markdown source.
Our converter handles the case where you already have Markdown text and need clean, basic HTML — without spinning up a static site generator, without copying through a CMS preview, without committing to a publishing toolchain. You paste Markdown, you get HTML, you copy the HTML wherever it needs to go.
The output is intentionally plain. There are no class attributes, no inline styles, no framework-specific markup. Block elements are wrapped in their canonical HTML tags. Inline elements use the standard equivalents. The result is portable HTML that works in any context that accepts HTML — email body, CMS field, custom HTML block in a website builder, raw output for further styling.
Why this converter exists alongside CMSes
Three patterns drive the demand. First, drafting outside a CMS: writers prefer Markdown for the same reasons developers do — fast typing, no mouse, no surprise formatting from rich-text toolbars, easy diff in version control. They draft in their editor of choice (Typora, Obsidian, VS Code, plain text), then need HTML to paste into a CMS that doesn't accept Markdown directly. Some CMSes accept Markdown natively; many do not, especially older or proprietary ones.
Second, transactional emails: marketing automation tools and transactional email services (SendGrid, Postmark, Mailgun) accept HTML body fields. Drafting an email in HTML is unpleasant; drafting in Markdown and converting is fast. The output HTML is portable enough that most email clients render it correctly without needing email-specific styling.
Third, embedding rich content in custom views: a static site generator might support Markdown in posts but not in widgets, sidebars, or footer blocks. A custom React component might accept HTML but not Markdown. Converting once and pasting the HTML solves the gap without building a Markdown parser into every consumer.
There are platform-specific Markdown-to-HTML conversions everywhere. Our converter is a general-purpose, no-CMS path — useful when you don't want to commit to a specific renderer's output and you just need a clean intermediate.
What the HTML output looks like
The converter produces these tags from these Markdown constructs:
- Paragraphs become
<p>...</p> - Bold (
**text**or__text__) becomes<strong>...</strong> - Italic (
*text*or_text_) becomes<em>...</em> - Strikethrough (
~~text~~) becomes<s>...</s> - Inline code (
`text`) becomes<code>...</code> - Code blocks (fenced
```) become<pre><code>...</code></pre> - Headings (
# H1through###### H6) become<h1>...</h1>through<h6>...</h6> - Links (
[text](url)) become<a href="url">text</a> - Bullet lists become
<ul><li>...</li></ul> - Numbered lists become
<ol><li>...</li></ol> - Blockquotes become
<blockquote>...</blockquote> - Line breaks inside a paragraph become
<br>
All text content is HTML-escaped. A < in your Markdown source becomes < in the output, a > becomes >, and so on. This is the standard HTML safety practice — the converter is safe to use on Markdown text that contains code samples or angle brackets without producing valid-looking HTML in the output.
The output omits a <!DOCTYPE html> wrapper, no <html>, <head>, or <body> elements. You receive a fragment, not a document. That is the right default — wrapping in a full HTML document is a one-line addition where you need it, but most consumers (CMS body fields, email body, embedded HTML blocks) want the fragment.
Before and after — three real cases
A documentation paragraph with inline code goes in:
The `convert()` function takes a string and an output format and returns a `ConversionResult` object. **Note**: the function is synchronous.
And comes out as:
<p>The <code>convert()</code> function takes a string and an output format and returns a <code>ConversionResult</code> object. <strong>Note</strong>: the function is synchronous.</p>
A small heading hierarchy with a list goes in:
## Setup
Before you start, install the dependencies:
- Node 20 or newer
- npm 10 or newer
- A GitHub personal access token with repo scope
And comes out as:
<h2>Setup</h2><p>Before you start, install the dependencies:</p><ul><li>Node 20 or newer</li><li>npm 10 or newer</li><li>A GitHub personal access token with repo scope</li></ul>
A blockquote with a link inside goes in:
> The classical theory was published in [The Origin of Species](https://en.wikipedia.org/wiki/On_the_Origin_of_Species) in 1859.
And comes out as:
<blockquote>The classical theory was published in <a href="https://en.wikipedia.org/wiki/On_the_Origin_of_Species">The Origin of Species</a> in 1859.</blockquote>
These are the comfortable cases. Output is clean and ready to drop into an HTML-accepting field.
URL safety and other guardrails
Link href values are sanitized before output. The accepted schemes are http, https, and mailto. A [click](javascript:alert(1)) becomes <a href="">click</a> (or omits the link entirely depending on the parser path) — the unsafe URL is dropped while the link text is preserved. A [file](file:///etc/passwd) is similarly rejected. This boundary is enforced for the same reason every browser HTML sanitizer enforces it: the converter must be safe to use on Markdown sourced from untrusted authors.
The text content of every node is HTML-escaped. A code block in Markdown that itself contains <script>...</script> produces <script>...</script> in the HTML output — visible as text inside the <pre><code> block, not as an executable script tag. This means you can convert Markdown documents that explain HTML or JavaScript without accidentally rendering the example code as live HTML.
The converter does not introduce inline style attributes or class attributes. There is no theme injection, no framework-specific markup, no CSS classes for syntax highlighting. The HTML you get is structural; styling is the consumer's job.
Coverage gaps — features the renderer skips
No syntax highlighting. Code blocks render as plain <pre><code>...</code></pre>. There are no language hints in the output, no <span class="hljs-...">, no Prism markup. If you need syntax highlighting, your destination renderer (Prism, Highlight.js, Shiki) takes the plain code block and applies highlighting at render time. The conversion produces clean source for that pipeline.
No anchor IDs on headings. The output <h2>Section title</h2> does not include an id attribute. Tools like GitHub, Substack, and most static site generators auto-generate slug-based IDs from heading text. If you need anchor IDs for in-page navigation, your destination renderer should add them.
No table support in the markdown source path. GFM pipe tables (|...|---|...|) are recognized by the parser but the AST does not expose a table node, so the table renders as paragraphs and may not produce a <table> wrapping. For tabular content, the dedicated CSV-to-Markdown converter (then a separate Markdown-to-HTML pass on its output) is the cleaner path. Tables generated from CSV produce GFM-compliant tables that render correctly on platforms that support GFM.
No image conversion at the URL level. A Markdown image () parses as a link in the AST. The converter does not produce <img src="..."> for images in this output path. For Markdown content with images, plan to either keep image references as Markdown that your destination renderer handles, or manually add <img> tags after the conversion.
No HTML pass-through. Markdown allows raw HTML inline (<div>...</div> inside a paragraph). The converter does not pass arbitrary HTML through to the output unchanged — text is escaped, structure is rebuilt from the AST. If your Markdown source needs raw HTML for a specific platform widget, that pass-through has to come from a different rendering pipeline.
No autolink for bare URLs. A line that contains just https://example.com is not auto-wrapped in an <a> tag in this conversion. To produce a link, write the Markdown link syntax: [https://example.com](https://example.com) or <https://example.com> (autolink syntax in some Markdown parsers).
No footnotes, definition lists, or task lists. GFM and various extended-Markdown specs include features like [^1] footnotes, term : definition definition lists, and - [x] task checkboxes. The current converter outputs these as approximate text rather than a dedicated HTML structure.
Choosing this over a full publishing pipeline
The Markdown-to-HTML route is the right choice when you have an isolated need — one paragraph, one email body, one CMS field, one widget — and you want predictable basic HTML without standing up a renderer. The output is small, clean, and works in nearly any HTML consumer.
It is the wrong choice when you need:
- Theme-aware HTML with class attributes (use a static site generator)
- Syntax-highlighted code blocks (use a renderer with a Prism/Shiki step)
- Anchor IDs on headings (use a renderer that adds them)
- Tables, footnotes, definition lists, task lists at full fidelity (use a GFM-extended renderer)
- A complete HTML document with
<head>and metadata (use a template wrapper)
For those cases the cost of the conversion is hidden inside a larger toolchain. For the everyday "paste Markdown, get HTML" job, the dedicated converter is faster, browser-only on web, and free to use within the daily limit.
The Telegram path runs the same engine. Send Markdown to @vustMarkdownBot and the reply contains both the rendered HTML output and a copy-ready Markdown view, useful when the same source needs to land in two destinations. Conversions through Telegram count against your bot crystal balance per the current pricing.
For everything more elaborate, the right move is to commit to a Markdown-aware publishing toolchain. For the cases this converter targets, simplicity is the feature.