Markdown Editor & Preview

Markdown preview for docs, READMEs, and changelogs

CommonMark reduces ambiguity vs older Markdown flavors, but tables, footnotes, and task lists still vary by renderer—preview before publishing to GitHub vs internal wikis.

Paste scrubbing: strip auth tokens from fenced code blocks before exporting HTML snapshots.

What the preview supports

The preview renders GitHub-Flavored Markdown (GFM) as you type: headings, emphasis, links, images, block quotes, ordered and unordered lists, inline code and fenced code blocks, horizontal rules, tables, task lists (- [ ] and - [x]), strikethrough (~~text~~) and automatic links for bare URLs.

Raw HTML is allowed — <kbd>, <sub>, <sup>, <details> and similar tags render as you would expect — but the output is sanitised, so scripts, event handlers such as onclick, and javascript: links are removed before anything is displayed. Copy HTML gives you that same sanitised markup, ready to paste into a CMS or an email template.

Syntax cheat sheet

# Heading 1 / ## Heading 2 / ### Heading 3
**bold**  *italic*  ~~strikethrough~~  `inline code`
[link text](https://example.com)
![alt text](https://example.com/photo.jpg)
> quoted text
- bullet item        1. numbered item
- [ ] open task      - [x] done task
---                  (horizontal rule)
| Column | Column |
| ---    | ---:   |   (:--- left, :---: centre, ---: right)
```js
code block with a language label
```

Mistakes that change the output

• Missing blank lines: a list, table or heading directly after a paragraph line may be swallowed into the paragraph. Put a blank line before block elements.
• Single line breaks: one newline inside a paragraph does not start a new line in GFM. End the line with two spaces or a backslash, or leave a blank line for a new paragraph.
• Indentation in nested lists: sub-items must be indented to line up under the parent item’s text — two spaces after “- ”, three after “1. ”.
• Underscores in words: snake_case_names are left alone in GFM, but *asterisks* in the middle of words still create emphasis. Wrap identifiers in backticks.
• Pipes in tables: a literal | inside a table cell must be escaped as \|.

Where your Markdown will end up

GitHub, GitLab, VS Code, Obsidian and most static-site generators use GFM or a close relative, so what you see here is a reliable preview for README files, issues and documentation. Some platforms differ: Reddit and Discord support only a subset (Discord has no tables), Slack uses its own “mrkdwn” with *single asterisks* for bold, and Jira uses a separate wiki syntax. Footnotes, math ($…$) and diagrams (Mermaid) are platform extensions this preview does not render: math and Mermaid code appear as plain text, and footnote definitions are hidden.

Everything stays in your browser — nothing you type is uploaded — so it is safe for drafting internal documentation. The text is not saved either: copy your work out before closing the tab.

A README structure that works

Most good README files answer the same questions in the same order. Paste this skeleton into the editor and fill it in:

# Project name

One sentence on what it does and who it is for.

## Installation

```bash
npm install my-package
```

## Usage

The shortest example that works.

## Configuration

| Option | Default | Description |
| --- | --- | --- |
| `debug` | `false` | Log extra detail |

## Contributing / License

Keep the first screen focused on what the project is and how to try it; move long reference material to separate pages and link to them.