Render Markdown to HTML Preview

Markdown source vs rendered output

Markdown source is what you type. Rendered output is what someone sees after the source passes through a renderer. The two are not the same. A source line containing **bold** is six characters long with two asterisks at each end; the rendered version is the word bold displayed in heavy weight, with no asterisks visible. The source is for authors; the rendered output is for readers.

The Markdown-to-rendered conversion takes Markdown source and produces a representation that stands in for the reader's view. That representation is not one fixed thing — it depends on where the output is going to be displayed. This page renders Markdown source into styled HTML: click Convert, and your source is sent to vust's server, which parses it and returns HTML markup for the preview pane to display — headings as real <h1>–<h6> elements, emphasis as <strong>/<em>, lists as <ul>/<ol>, and so on. The same underlying source has a second, separate rendering target: the Telegram bot @vustMarkdownBot, which turns Markdown into the plain-text-plus-entities format a Telegram client renders natively. Both are real "rendered" outputs of the same Markdown source; they are just built for different consumers, and this page covers the HTML target in depth.

The conversion is the bridge between Markdown source — easy to write, easy to version-control, portable across documentation tools — and whichever display surface actually shows it to a reader. If you're drafting a README, a blog post, or a doc page in Markdown and want to see how it will actually look before you publish it, the HTML preview is the fast way to check without pushing to the real destination first.

What "rendered" means on this page

For this tool, "rendered" means HTML: a string of markup — <p>, <h2>, <strong>, <code>, <ul>, <blockquote>, and so on — that a browser can display directly as styled text, with no Markdown syntax left visible. The preview pane on this page loads that HTML inside a sandboxed frame with a small built-in stylesheet (system font, padded body, a light background behind code blocks, an indent-and-border treatment for blockquotes) so the result looks like a plain, readable document rather than raw markup.

Getting that HTML is a click-to-render step, not a live preview: the widget posts your Markdown source to the conversion endpoint, waits for the response, and then loads the returned HTML into the preview frame. Nothing updates as you type — edit the source, click Convert again, and the preview refreshes with the new result. This matters if you're iterating on a document: change a heading level or reword a sentence, then re-run the conversion to see the updated rendering.

This is a different model from Telegram's. Telegram clients don't render HTML — they render a plain text string plus a separate array of formatting "entities," each one a type (bold, italic, code, text_link, pre, …) with a UTF-16 offset and length pointing back into the text. The visible text carries no markup at all; the styling lives entirely in the accompanying entity list. HTML and Telegram entities are two different representations of the same idea — "here is where the reader sees styled text instead of raw source" — built for two different rendering engines.

A second real target: the Telegram bot

The Telegram bot at @vustMarkdownBot accepts Markdown source as a message and replies with the Telegram-entity version of the same content — the form a Telegram client renders as styled text directly in the chat. That is a genuinely different output from this page's HTML: same Markdown in, but the bot's reply is a { text, entities } pair built for Telegram's renderer, not an HTML document built for a browser.

If your destination is a Telegram chat or channel rather than a web page, the bot is the right tool, not this one — sending HTML markup into a Telegram message would just show up as literal angle brackets. For the mechanics of how Telegram's entity model works and how vust's converter maps Markdown constructs onto it (including which constructs Telegram has no equivalent for), the telegram-to-markdown conversion on this site documents the entity model in depth from the reverse direction; the same entity structure is what @vustMarkdownBot produces when it renders Markdown forward into a Telegram-ready message.

The rest of this page covers the HTML target, since that's what the widget above produces.

How the engine builds the HTML output

The conversion is a two-step path:

1. Parse the Markdown source into an internal structure. The parser uses marked configured for GitHub-Flavored Markdown, walking the source into tokens for block constructs (paragraphs, headings, lists, blockquotes, code blocks, tables) and inline constructs (bold, italic, strikethrough, inline code, links, images).
2. Render that structure as HTML tags. Each recognized construct maps to a specific HTML element, and the renderer concatenates them into one markup string.

For each construct, the renderer makes a deliberate choice about how to map it:

• Paragraphs become <p>…</p>.
• Headings (# through ######) become <h1> through <h6>, matching the source's heading level.
• Bold, italic, strikethrough wrap their inner text in <strong>, <em>, and <s> respectively.
• Inline code (single backticks) becomes <code>…</code>.
• Code blocks (triple-backtick fences) become <pre><code>…</code></pre> with the code content escaped as literal text.
• Links become <a href="…">…</a>.
• Bullet and numbered lists become <ul>/<ol> with each item as <li>, including nested lists inside a nested <ul>/<ol>.
• Blockquotes become <blockquote>…</blockquote>, wrapping the quoted paragraphs inside.

Three GFM constructs are worth calling out because the output is not what you might expect from a full Markdown renderer:

• Code-block language hints are not preserved. A fence written as ```js still produces plain <pre><code>, with no class="language-js" or similar attached — there is no syntax-highlighting step in this preview, so the language hint has nowhere to attach.
• Tables do not become <table> markup. GFM pipe tables are recognized by the parser, but the renderer flattens each table back into a plain pipe-delimited text block wrapped in <pre><code> — the same monospace treatment as a code block — rather than building <table>/<tr>/<td> elements.
• Images become links, not <img> tags. An inline ![alt text](url) is recognized, but the renderer turns it into <a href="url">alt text</a> — a clickable link showing the alt text — rather than embedding the image.
• Inline and block math syntax passes through as literal text. $x^2$ or $$x^2$$ in the source is not recognized as a math construct; it renders inside its paragraph exactly as typed, dollar signs and all, with no LaTeX rendering applied.

If your document leans on real HTML tables, embedded images, syntax-highlighted code, or math notation, plan around these gaps: convert a table to a short bullet list if a visual table matters, keep images as separate assets referenced by a caption rather than relying on the preview to embed them, and treat code blocks as plain formatted text rather than a highlighted snippet.

Before/after — source and rendered preview

A Markdown paragraph with mixed inline emphasis goes in:

The **convert()** function is *synchronous* and returns a `result` object.

The rendered HTML that comes back:

<p>The <strong>convert()</strong> function is <em>synchronous</em> and returns a <code>result</code> object.</p>

Loaded into the preview frame, the reader sees: "The convert() function is synchronous and returns a result object." with bold, italic, and inline code rendered visually — no asterisks or backticks left on the page.

A bullet list with a link goes in:

- First item
- Second item with [link](https://example.com)
- Third item

Rendered HTML:

<ul><li>First item</li><li>Second item with <a href="https://example.com">link</a></li><li>Third item</li></ul>

The browser renders this as an actual bulleted list with a clickable link on the second line, styled by the preview frame's bullet indent and link color.

A blockquote with two paragraphs and a heading above it goes in:

## A short note

> The mind is *everything*.
>
> What you think, you become.

Rendered HTML:

<h2>A short note</h2><blockquote><p>The mind is <em>everything</em>.</p><p>What you think, you become.</p></blockquote>

The heading renders as a real, styled <h2>, and the blockquote wraps both quoted paragraphs with the preview frame's left-border-and-indent treatment — a genuinely different visual result from the flat, unstyled Markdown source above it.

What carries over cleanly, and what to watch for

Plain prose, headings, emphasis (bold/italic/strikethrough), inline code, fenced code blocks, links, ordered and unordered lists (including nesting), and blockquotes all map onto real, distinctly styled HTML elements — this is the bulk of what a typical README, blog draft, or documentation page is made of, and it comes through as a faithful, readable preview.

Outside that set, a few things are worth knowing before you rely on the preview for something specific:

Long documents produce long HTML. There's no highlighting or table layout to compress the output, so a large source document produces a correspondingly large HTML string; the preview frame scrolls to accommodate it, but very long pastes make for a long scroll rather than a paginated view.

Nested emphasis compounds as nested tags. Bold-inside-italic-inside-a-link produces nested <strong>/<em>/<a> tags around the same text range — visually correct, but worth knowing if you're inspecting the HTML output directly rather than just the preview.

Raw HTML in the source is treated as literal text, not re-parsed. If your Markdown source already contains an HTML snippet (say, a hand-written <table> block), the parser reading Markdown syntax does not interpret it as markup — it comes through as visible, escaped text in the output rather than being rendered.

Horizontal rules become a plain text separator, not an <hr> element — a source line of --- on its own renders as the literal text "---" inside a paragraph rather than a horizontal line.

For a full list of constructs that map onto Telegram's entity model differently — including which ones Telegram drops entirely, like headings needing to be re-expressed as bold text — see the entity-model detail on the telegram-to-markdown page; that detail applies to the @vustMarkdownBot target, not to this page's HTML preview.

Pairing the preview with the bot

The Markdown-to-rendered conversion has two practical, separate surfaces built from the same source:

The web tool at vust.ai/markdown/markdown-to-rendered accepts Markdown source and, on a Convert click, shows the rendered HTML preview. This is the right place to draft and check a document before publishing it somewhere that displays HTML — a blog post, a documentation page, a README preview — write the Markdown, convert, look at the styled result, adjust the source, convert again.

The Telegram bot @vustMarkdownBot accepts Markdown source as a message and replies with the Telegram-entity version, ready to forward or copy into a chat. If your destination is a Telegram conversation rather than a web page, send your draft to the bot instead of relying on this page's HTML preview — the two targets produce genuinely different output formats from the same input.

The pairing is most useful for anyone who drafts the same content for more than one destination: write once in Markdown, keep it version-controlled and reviewable, then convert it into whichever rendered form the destination actually needs — HTML for a page, entities for a Telegram message.

For a one-off document check (previewing a README before committing it, checking how a blog draft's headings and code blocks will look), the web tool is the faster path — paste, click Convert, read the preview. For a message headed into a Telegram chat, the bot is the correct target, since only its output actually displays inside Telegram the way the source intends.

The result is a deliberate, purpose-specific conversion: faithful for the constructs each rendering target actually supports, and about the handful that don't carry over — flattened tables, linked-not-embedded images, unrendered math, unhighlighted code — so you know upfront what the preview will and won't show you.