Markdown Preview

Write Markdown and see a live HTML preview.

What Markdown Preview helps you do

Write Markdown on one side and see the rendered HTML on the other. It is the fast way to check formatting before committing a README or pasting into a docs system. The renderer is the marked library loaded from a CDN, and the preview updates as you type.

Preview rendering happens in your browser. Nothing is sent to Haivix, though the renderer is loaded from a public CDN.

How it works

These tools transform text locally: they parse, format, encode or render a string in your browser. Nothing you paste is uploaded to Haivix, but some tools load a library from a public CDN, so the page needs a network connection and your browser makes that request. The transformations operate on syntax, not meaning: a formatter can make invalid code look tidy, an encoder can hide a value without protecting it, and a preview can render markup that was never meant to execute. Outputs are exact strings, which means line endings, byte order marks and character encoding all matter when you paste the result somewhere else.

How to use Markdown Preview

  1. Type or paste Markdown into the input.
  2. Read the live rendered preview beside it.
  3. Check headings, lists, links and code blocks.
  4. Copy the Markdown when you are satisfied.

When to use it

  • Preview a README before pushing it to a repository.
  • Check headings, lists and links in a document draft.
  • Convert Markdown into HTML for a page.
  • Test how a table or code fence renders.
  • Check a link before publishing it.
  • Compare the source and rendered layout side by side.

When not to use it

  • Do not treat the preview as sanitized; raw HTML passes through.
  • Do not expect GitHub-specific extensions such as task lists or alerts.
  • Do not use it to publish untrusted Markdown without a server-side sanitizer.

Example

A hash and a space before a line becomes an HTML heading in the preview. A fenced code block renders as preformatted text, and inline backticks become code. An inline HTML tag in the Markdown is passed through, so an image with an event handler could run in the preview.

What you can do with Markdown Preview

  • Render Markdown live in a side-by-side preview.
  • Support common headings, lists, links, code and emphasis.
  • Pass raw HTML through to the preview.
  • Start from a small example document.
  • Update the preview on every keystroke.
  • Keep the Markdown in the browser.

Example: test with a real sample before trusting the output

Keep the original text. These tools produce a new value rather than editing in place, so a bad transform is reversible only if you still have the source.

Test with a representative sample, including the awkward case: a quote inside a string, a tag inside an attribute, a newline in the middle of a value.

Check line endings and encoding when moving between Windows, Unix and a browser form. A trailing carriage return can break a signature or a hash.

Treat pasted HTML and Markdown as untrusted. A preview that renders raw markup can execute event handlers even when it looks harmless.

Verify the result with the real parser, compiler or linter before shipping. A browser-side formatter is a convenience, not a substitute for the toolchain.

Prefer exact values over screenshots or copied rendered text. Rendering can normalize quotes, dashes and spaces in ways that break the next tool in the chain.

What to know before you start

  • The renderer supports common Markdown and may not cover every extended syntax.
  • It does not sanitize every possible input, so treat pasted HTML with care.
  • There is no copy-HTML button; the output is a preview, not an export you can paste.
  • The renderer library is fetched from a public CDN.

Common mistakes

  • Assuming the preview sanitizes embedded HTML.
  • Expecting front matter to be hidden or parsed.
  • Using an extension the renderer does not support and blaming the syntax.
  • Pasting untrusted content and clicking a rendered link.

Troubleshooting

If the preview stays empty, the renderer may still be loading from the CDN.

If a table does not render, the syntax may not be supported without an extension.

If raw HTML appears as text, it may be escaped by the input path.

If links do not work, the preview may be blocking navigation.

Related standards and documentation

  • ECMA-404 defines JSON, and RFC 8259 defines its media type.
  • XML 1.0 is a W3C Recommendation; schemas are defined separately by XSD.
  • ECMA-262 defines JavaScript, including its regular expression syntax.
  • RFC 3986 defines URI syntax and percent-encoding.
  • CommonMark specifies Markdown, though many renderers extend it.
  • The HTML Living Standard defines character references and parsing rules.
  • Unicode defines the character encodings behind text and entity handling.
Syntax, not semantics
  • Keep the source.
  • Test the awkward case.
  • Check encoding and newlines.
  • Verify with the real tool.