Back to HomeWeConvertFiles Guide

Preview Markdown as Rendered HTML While You Type

Live Rendering

Markdown adds structure to plain text with a small set of readable characters. The Markdown Preview tool converts the text you enter into HTML and updates the preview live using the marked JavaScript library. It is useful for drafting README files, documentation, articles, and issue text — but it does not guarantee that GitHub or another engine will produce exactly the same result. The current implementation inserts the rendered HTML directly and does not add a separate sanitization step, so use content you trust, especially when the Markdown contains raw HTML.

Open Markdown Preview

Quick answer. Write or paste Markdown and inspect the live output. Use the preview to catch structural mistakes, then verify the final source in the exact platform where it will be published. Do not paste untrusted Markdown containing HTML into the current tool.

What the Markdown preview does

It does

  • • Accepts Markdown text in an editor
  • • Calls marked.parse() as the input changes
  • • Inserts the returned HTML into a live preview
  • • Expands the preview layout when content is present
  • • Supports the features of the installed marked version

It does not

  • • Upload, open, or download files
  • • Save drafts or version history
  • • Guarantee GitHub-identical output
  • • Resolve every relative image or link as published
  • • Add a separate HTML sanitization layer
  • • Provide collaborative editing or comments

Markdown source and rendered output

Markdown is the source format:

## Release notes

The update includes:

- Faster startup
- Improved search
- Clearer error messages

A renderer turns that source into HTML resembling:

<h2>Release notes</h2>
<p>The update includes:</p>
<ul>
  <li>Faster startup</li>
  <li>Improved search</li>
  <li>Clearer error messages</li>
</ul>

The exact HTML and visual styling depend on the renderer, its options, and the CSS of the website displaying it.

How to preview Markdown

  1. 1. Identify the destination. Decide where the Markdown will be used — GitHub, a documentation generator, a CMS, an issue tracker, a chat app, or another platform. Each can support a different Markdown flavor and security policy.
  2. 2. Write or paste the source. Use clear structure and representative features such as headings, nested lists, code fences, links, tables, or blockquotes. Avoid placing sensitive tokens, private URLs, credentials, or personal data into examples.
  3. 3. Inspect the live preview. Check heading hierarchy, paragraph spacing, list nesting, code formatting, link text and destinations, image descriptions, table structure, blockquote boundaries, and escaped punctuation.
  4. 4. Correct the source. Fix ambiguous nesting, unmatched delimiters, missing blank lines, unclosed code fences, and malformed links.
  5. 5. Verify in the publishing platform. Paste or commit the final source into the actual destination and preview it again. The destination's renderer and CSS are authoritative for the published result.

Common Markdown syntax

Headings. Use one to six hash characters followed by a space, in a logical hierarchy — do not choose a level only for its visual size. Prefer one H1 for the title, H2 for primary sections, and H3 for subsections, avoiding skipped levels.

# Page title
## Major section
### Subsection

Paragraphs and line breaks. Separate paragraphs with a blank line. A single source line break may be treated as ordinary whitespace by some renderers, and forced line-break syntax varies, so prefer normal paragraphs unless the destination requires manual breaks.

Emphasis. *Emphasized*, **Strong**, and ***Strong emphasis***. Underscores can also work but may interact with words containing underscores, so asterisks are often clearer in technical writing. Use emphasis sparingly.

Lists. Use - for unordered items and 1. for ordered items. Indent nested items consistently; the exact spaces required can vary between renderers, so verify complex lists on the destination.

- PDF tools
  - Merge
  - Rotate
- Text tools
  - Format JSON
  - Test regex

Links. Inline [text](url) or reference-style links for long documents. Use descriptive link text, confirm the destination, prefer HTTPS, be cautious with user-supplied URLs, and check relative links from the final document location. "Click here" is less useful than text that describes the destination.

[Visit WeConvertFiles](https://www.weconvertfiles.com/)

Read the [format guide][guide].

[guide]: https://example.com/guide

Images. ![description](url) — the bracketed text is the alternative text. Write useful alt text when the image conveys information. Relative image paths may fail in the preview because its base URL differs from the future file's location.

Inline code and code blocks. Use single backticks for inline code and triple backticks for blocks. A language identifier can enable syntax highlighting where supported. If the example itself contains triple backticks, wrap it with a longer fence.

Blockquotes and horizontal rules. Start quoted lines with >; use --- on its own line, surrounded by blank lines, for a horizontal rule. Use both sparingly — clear headings usually provide better navigation than rules.

Tables and task lists. Many implementations support pipe tables with optional alignment markers, and some support - [x] task lists. Neither is part of every Markdown baseline, so confirm support on the target flavor.

| Tool | Output |
|---|---|
| JSON Formatter | Formatted JSON |
| Regex Tester | Highlighted matches |

Escaping punctuation. Use a backslash when punctuation should appear literally instead of starting formatting. Inside code spans and fenced blocks, most Markdown punctuation is already treated as code, so code fences are clearer than repeatedly escaping.

Markdown flavors differ

"Markdown" refers to a family of related syntaxes rather than one universal renderer — original Markdown, CommonMark, GitHub Flavored Markdown, documentation-generator extensions, CMS shortcodes, and chat or issue-tracker subsets.

Differences may affect tables, task lists, automatic URL linking, strikethrough, footnotes, heading identifiers, definition lists, raw HTML, line breaks, syntax highlighting, emoji and mentions, and link sanitization. Treat the target platform's documentation and preview as the final authority.

How the live preview works

  1. 1. Listens for changes in the Markdown input.
  2. 2. Trims the input to determine whether content is present.
  3. 3. Passes the source to marked.parse().
  4. 4. Assigns the returned HTML to the preview container with innerHTML.
  5. 5. Expands the layout from a two-column empty state into a larger preview when text is present.
  6. 6. Adjusts preview height within its current limits (about 420px minimum, capped near 720px).

The marked library may be downloaded from a third-party content-delivery network when the tool opens, so rendering should not be described as completely offline merely because the Markdown content is processed in the browser.

Important security warning: raw HTML

Markdown can contain raw HTML when the renderer permits it. The current preview inserts the rendered result into the page and does not add a separate sanitizer such as DOMPurify. Do not paste untrusted Markdown containing HTML, event-handler attributes, embedded resources, or other active markup into the current tool. Content to treat cautiously includes:

<img src="..." onerror="...">
<iframe src="..."></iframe>
<svg><!-- active or external content --></svg>

Encoding these examples in documentation does not make arbitrary pasted HTML safe in the live preview. A production publishing pipeline should define an explicit HTML policy and sanitize untrusted rendered output with a well-maintained sanitizer. Escaping all HTML may be more appropriate when raw HTML is unnecessary.

Previewing is not sanitizing

Rendering answers "how does this Markdown become HTML?" Sanitizing answers "which elements, attributes, protocols, and embedded resources are allowed to remain in that HTML?" Those are separate operations.

A parser can correctly render Markdown and still produce HTML that should not be inserted into a page without sanitization. Do not assume that content is safe because the preview looks normal.

Relative links and images

The preview page has its own URL, and relative references are resolved from that context, which may differ from the eventual Markdown file. Paths like these may be correct in a repository but broken in the standalone preview:

[Setup](../docs/setup.md)
![Logo](./assets/logo.png)

Verify relative resources after the file has been placed in its actual directory. Avoid rewriting correct repository-relative paths merely to make the temporary preview load them.

Accessibility and SEO checks

Accessibility

A visual preview does not replace accessibility review. Check one clear title, logical heading order, descriptive link text, useful image alt text, real table headers, lists used as lists, clearly identified code, sufficient contrast in the final theme, and keyboard/screen-reader behavior in the publishing platform.

SEO

When Markdown becomes a page, use a descriptive H1, organize sections under informative H2s, answer the main question early, write descriptive link text, add image alt text, and provide metadata through the publishing system. SEO depends on the final HTML, canonical URL, internal links, performance, structured data, and content quality — not syntax alone.

Privacy and data handling

Markdown content is passed to the renderer in browser memory and is not sent to WeConvertFiles for preview generation. The marked library may be fetched from a third-party CDN when required.

If a visitor consents to site analytics, separate usage information such as visits, clicks, device details, or tool interactions may be collected. Those analytics do not receive the Markdown source entered into the editor.

The local environment still matters. Browser extensions, malware, clipboard managers, screen recording, shared devices, and active resources referenced by pasted HTML can expose information independently of the tool. Do not paste secrets, private links, unpublished customer data, or untrusted raw HTML into the preview.

Limitations

  • • Output depends on the installed marked version and configuration.
  • • The result may differ from GitHub or another destination.
  • • No separate HTML sanitization step is applied.
  • • No upload, download, autosave, history, or collaboration.
  • • Relative links and images may resolve differently.
  • • Syntax highlighting depends on the available presentation layer.
  • • The preview is not a full accessibility, link, or security audit, and does not publish the document.

Troubleshooting

A feature looks different on GitHub

GitHub uses GitHub Flavored Markdown and its own rendering and sanitization pipeline. Test the source in GitHub before publishing.

A code block consumes the rest of the document

Close the fence with the same marker and at least the same number of backticks or tildes used to open it.

A nested list is not nested

Indent child items consistently and add blank lines when required by the destination renderer.

A relative image is broken

The preview's base URL differs from the final file location. Verify the path after placing the Markdown in its actual repository or site directory.

Raw HTML behaves unexpectedly

Do not preview untrusted HTML. The current implementation does not add a separate sanitization layer, and different Markdown destinations allow different HTML subsets.

A table is displayed as plain text

The renderer or destination may not support pipe tables, or the separator row may be malformed. Check the target flavor.

A heading does not appear in a table of contents

Automatic heading IDs and table-of-contents generation are platform features, not universal Markdown behavior.

The preview becomes scrollable

The interface limits preview height for usability. Scrolling does not mean the rendered content is truncated from the source.

Frequently asked questions

Which Markdown renderer does the tool use?

It uses the marked JavaScript library loaded in the browser.

Is the preview identical to GitHub Markdown?

No. GitHub uses its own flavor, renderer configuration, extensions, and security pipeline.

Does the preview update automatically?

Yes. It rerenders as the input changes.

Can I upload or download a Markdown file?

No. The current tool provides a text editor and live preview only.

Are drafts saved?

The tool does not intentionally persist editor content or provide version history.

Can Markdown include HTML?

Some renderers, including configurations of marked, can pass through raw HTML. The destination's policy may differ.

Is pasted HTML sanitized?

No separate HTML-sanitization step is applied by the current preview. Do not paste untrusted Markdown containing HTML.

Why are relative links or images broken?

They are resolved from the preview page rather than the final Markdown file's future location.

Does the tool publish my Markdown?

No. It only renders a local preview in the browser.

Is Markdown good for SEO?

Markdown can support well-structured content, but SEO depends on the final HTML, metadata, canonical URL, internal links, performance, accessibility, and usefulness.

Related tools

Diff Checker

Compare two Markdown drafts as text.

Word Counter

Measure draft length and reading time.

Regex Tester

Test text patterns with controlled plain-text samples.

Related guides

QR Code Generator Guide

Generate high-quality custom QR Codes for any URL, text, or phone number instantly.

Word & Character Counter Guide

Live-updates word, character, and paragraph counts plus a reading-time estimate.

JSON Formatter / Validator Guide

Format, validate, beautify, and minify raw JSON string data dynamically.

Preview your Markdown live

Draft your headings, lists, links, and code, watch the live HTML, then confirm the final source in the platform where it will publish.

Use Markdown Preview