Write Markdown on the left — see formatted output on the right. Export HTML or PDF, sync scroll, copy source.
Write Markdown on the left — the rendered output updates on the right.
inline codefunction greet(name: string) {
return `Hello, ${name}!`
}
Blockquotes and tables:
| Feature | Supported |
|---|---|
| GFM tables | Yes |
| Fenced code | Yes |
These elements are part of the original Markdown specification and are supported by every Markdown renderer — GitHub, VS Code, Notion, Obsidian, MkDocs, and this preview tool.
| Element | Syntax | Notes |
|---|---|---|
| Heading 1 | # Heading 1 | Leave a space after # |
| Heading 2 | ## Heading 2 | |
| Heading 3 | ### Heading 3 | |
| Bold | **bold text** | Also: __bold text__ |
| Italic | *italic text* | Also: _italic text_ |
| Bold + italic | ***bold italic*** | |
| Inline code | `code` | Backtick wraps the span |
| Link | [label](https://url.com) | |
| Image |  | Alt text improves accessibility |
| Blockquote | > quoted text | Nest with >> for deeper quotes |
| Horizontal rule | --- | Also: *** or ___ |
| Ordered list | 1. First 2. Second | Numbers don't need to be sequential |
| Unordered list | - Item - Item | Also: * or + |
GFM is a superset of CommonMark developed by GitHub and adopted by most modern tools. These elements are not in the original Markdown spec but are supported here and in GitHub, GitLab, VS Code, and most documentation platforms.
| Element | Syntax | Notes |
|---|---|---|
| Strikethrough | ~~deleted text~~ | GFM only |
| Task list | - [x] Done - [ ] To do | GFM only — renders as checkboxes |
| Table | | Col 1 | Col 2 | |-------|-------| | A | B | | Pipes don't need to align |
| Fenced code block | ```js const x = 1 ``` | Language tag enables syntax highlighting |
| Autolink | https://example.com | Bare URLs become links in GFM |
| Footnote | text[^1] [^1]: footnote | Not in all GFM implementations |
Markdown is intentionally simple, but a few whitespace rules catch almost everyone at least once.
Here are the steps: 1. Install dependencies 2. Run the build 3. Deploy
Here are the steps: 1. Install dependencies 2. Run the build 3. Deploy
Most Markdown parsers require a blank line between a paragraph and the list that follows it. Without the blank line, the items render as plain text continuation of the paragraph rather than a numbered list.
## Section One Some content here. ## Section Two More content.
## Section One Some content here. ## Section Two More content.
In some parsers, a heading immediately followed by a paragraph without a blank line merges them. The safe convention — and what all major renderers expect — is one blank line between every block element.
```
const greet = (name) => `Hello, ${name}`
``````js
const greet = (name) => `Hello, ${name}`
```Without a language tag after the opening triple backtick, the code block renders as plain text with no syntax highlighting. GitHub, VS Code, and most documentation renderers support language identifiers: js, ts, python, go, bash, json, yaml, sql, html, css, and many more.
Use * for multiplication and _ for subscript.
Use \* for multiplication and \_ for subscript.
Asterisks, underscores, backticks, brackets, and other Markdown-special characters are interpreted as formatting syntax. Prefix them with a backslash (\) to render them literally. The characters that need escaping: \ ` * _ { } [ ] ( ) # + - . !
No. Parsing, preview rendering, copy, HTML export, and PDF export all run locally in your browser using JavaScript. Open the Network tab in DevTools while using the tool — you will not see your document sent anywhere. There is no server receiving your text.
The preview renders GitHub Flavored Markdown (GFM) — the superset of CommonMark used by GitHub for README files, issues, and pull requests. This includes standard Markdown (headings, bold, italic, lists, links, images, blockquotes, code) plus GFM extensions: tables, task lists, strikethrough, fenced code blocks with language tags, and autolinked URLs.
CommonMark is a standardised specification for core Markdown syntax. GitHub Flavored Markdown (GFM) is a superset — it adds tables, task lists, strikethrough, fenced code blocks, and autolinks. Most online Markdown tools use one or the other. This tool renders GFM, which covers what most developers encounter day-to-day.
When sync scroll is on, scrolling the Markdown editor moves the preview proportionally, and scrolling the preview moves the editor. The scroll position is mapped as a ratio of the total scrollable height of each pane, so the two sides stay roughly aligned even when the rendered HTML is a different length to the raw Markdown. Turn it off if you want to read one pane while keeping the other at a different position.
PDF export rasterizes the rendered preview panel (similar to a screenshot) and places it across A4 pages. Very long documents span multiple pages automatically. Because it captures the visual output, the PDF matches the preview exactly — including code block styling, table borders, and any custom colours. For a text-based, copy-pasteable PDF, paste the rendered HTML into a word processor or use a Markdown-to-PDF CLI tool like Pandoc.
Yes — that is one of the primary use cases. This tool renders the same GFM flavour GitHub uses for README, CONTRIBUTING, and wiki files. What you see in the preview is a close match to what GitHub will render. Write your README here, then copy the Markdown source directly into your .md file.
Use triple backticks followed immediately by the language identifier: ```js for JavaScript, ```python for Python, ```bash for shell scripts, ```json for JSON, ```sql for SQL, and so on. The language tag must appear on the same line as the opening backticks with no space. Most major programming languages and data formats are supported.
The most common cause is a missing blank line between the preceding paragraph and the list. Add an empty line before the first list item. The second most common cause is inconsistent indentation on nested lists — use exactly 2 or 4 spaces (or one tab) per nesting level. Mixing tabs and spaces causes unpredictable results in most parsers.