Markdown 编辑器，免费
编写 Markdown，实时查看 HTML 预览。
使用方法
- 在左侧面板输入或粘贴 Markdown 文本。右侧面板显示实时 HTML 预览。
- 使用工具栏按钮快速插入格式（粗体、斜体、标题、链接等）。
- 在编辑器下方查看字数、字符数和行数。
- 下载您的 Markdown 为 .md 文件，或复制 HTML 输出。
常见问题
此编辑器支持标准 Markdown 语法吗？
支持。它支持标题、粗体、斜体、链接、图片、代码块、列表、引用和水平线。简化的 Markdown 解析器会实时渲染 HTML。
可以保存我的工作吗？
编辑时，编辑器会自动将文本保存到浏览器存储中。使用下载 .md将其保存为本地文件。
如何插入链接或图片？
使用工具栏按钮。链接使用 [文本](url)。图片使用 。预览会立即更新。
A short history of Markdown
Markdown was created in March 2004 by John Gruber, the writer behind Daring Fireball, with significant collaboration from Aaron Swartz (the polymath who later co-founded Reddit and co-authored the RSS 1.0 spec). The stated design goal (written into the original syntax page) was "to make it as readable as possible." Gruber wanted a plain-text format that was publishable as-is, looking natural in a terminal or a plain-text editor without any rendering at all. The format formalised what people were already doing in plain-text email and Usenet posts: *asterisks for emphasis*, > for quoted text, blank lines between paragraphs.
The name is a play on "markup language", Markdown is so light that it "marks down" rather than marking up. The philosophical core that distinguishes it from HTML: HTML's source is for machines, Markdown's source is for humans. A .md file should be perfectly comfortable to read in a terminal with no rendering applied.
Gruber's original syntax page left many edge cases ambiguous, and through the late 2000s every project that needed a Markdown parser wrote its own, making different decisions about the unspecified bits. By the early 2010s the same .md file rendered visibly differently on Reddit, GitHub, Stack Overflow and a Jekyll blog. In 2014, a working group including Jeff Atwood (Stack Overflow, Discourse), John MacFarlane (Pandoc), and engineers from GitHub, Reddit and Meteor produced a rigorous spec, originally called "Standard Markdown," renamed CommonMark after Gruber objected. CommonMark publishes both human-readable prose and a machine-readable test suite of 600+ edge-case tests; the current version is 0.31.2 (January 2024). GitHub, GitLab, Reddit, Stack Overflow, Discourse and dozens of programming languages now claim conformance.
Common syntax
This is the syntax that works in nearly every Markdown flavour, the practical baseline this editor supports.
| What you want | How to write it |
|---|---|
| Heading | # H1 through ###### H6 |
| Bold / italic | **bold** · *italic* · ***both*** |
| Inline code | `code` |
| Code block | Fenced with three backticks; optional language tag for syntax highlighting |
| Unordered list | - item (or * or +) |
| Ordered list | 1. first: actual numbers usually don't matter |
| Link | [text](https://example.com) |
| Image | : alt text matters for accessibility |
| Blockquote | > quoted text |
| Horizontal rule | --- on a line by itself |
Two common gotchas: a single newline does not create a line break: you need a blank line for a new paragraph, or two trailing spaces before the newline (or in GFM, a backslash) for a forced line break inside a paragraph. And Markdown is a superset of HTML: any inline HTML tags pass through to the rendered output, which is occasionally useful and occasionally a security risk.
GitHub Flavored Markdown and other flavours
GFM is GitHub's superset of CommonMark. It adds tables (pipe-delimited rows with a hyphen separator), task list items (- [ ] unchecked, - [x] checked), strikethrough (~~text~~), automatic URL detection, and a "disallowed raw HTML" filter that strips dangerous tags. GitHub itself also renders some non-spec extras, emoji shortcodes (:tada:), @mentions, #123 issue autolinks, alert callouts (> [!NOTE]), collapsible <details> sections, but these are GitHub render features rather than parts of the GFM spec.
Other flavours you'll meet:
- Pandoc Markdown: adds metadata blocks, footnotes, definition lists, math (
$...$LaTeX), citations. The "swiss army knife" universal-document version. - MultiMarkdown and Markdown Extra: earlier extended flavours that influenced GFM's table syntax.
- R Markdown: wraps Markdown around executable R or Python code chunks; renders to HTML/PDF/Word via Pandoc.
- MDX: Markdown plus JSX. Used in React-based documentation (Docusaurus, Next.js MDX).
- Discord uses a deliberate subset; Slack uses an intentionally non-standard variant called "mrkdwn" with single-asterisk bold and single-underscore italic. Pasting standard Markdown into Slack gives surprising results.
Where Markdown lives
Pretty much everywhere developers write text:
- Code hosting: every GitHub README, issue, and PR comment; same on GitLab, Bitbucket, Codeberg, Gitea.
- Q&A and forums: Stack Overflow, Stack Exchange, Reddit, Discourse.
- Note-taking: Obsidian, Joplin and Logseq use Markdown natively. Notion and Bear export to it.
- Static site generators: Jekyll (Ruby, Kramdown), Hugo (Go, Goldmark), Eleventy (Node, markdown-it), Docusaurus, MkDocs, Astro.
- Documentation tools: JSDoc, TypeDoc, Rustdoc (Rust uses CommonMark for
///doc comments), Sphinx via MyST. - Modern chat: Mattermost, Zulip, Element/Matrix all use Markdown for message formatting.
Markdown is also a registered IETF media type (text/markdown, RFC 7763, March 2016) with a variant parameter (GFM, CommonMark, MultiMarkdown, etc.) so receivers know which flavour to apply. Common file extensions: .md by far the most popular, plus .markdown, .mdown, .mkdn, .mkd.
A note on this editor's parser
This page uses a simplified Markdown parser that covers the common subset above, headings, bold and italic, links, images, fenced code, lists, blockquotes, and horizontal rules. It is not a full CommonMark or GFM implementation and may not handle every edge case (deeply nested lists with mixed bullets, lazy line continuation, link-reference definitions across the document). For mission-critical CommonMark conformance, a dedicated parser like marked.js, markdown-it, or commonmark.js is the right choice, and for production rendering of untrusted Markdown, pipe the parser's output through a sanitiser like DOMPurify to prevent XSS through inline HTML.
When you'd reach for this
- Drafting a GitHub README with live preview before pasting into the repo.
- Writing a blog post for a Jekyll, Hugo, Ghost or Eleventy site whose source files are
.md. - Prototyping a Notion or Obsidian note when you don't want to open the desktop app.
- Converting a quick snippet to HTML for embedding in a CMS, an email, or a Slack canvas.
- Learning Markdown syntax: the live preview shows immediately what each character does.
- Drafting confidential content: the editor auto-saves to your browser's
localStorage, so a sensitive contract clause or pre-launch announcement never leaves your device.
More questions
Why doesn't a single line break create a new line?
By design. Markdown collapses single newlines into a continuing paragraph because the format is meant to look natural as plain text, readers wrap at arbitrary widths in their editor without breaking the rendered output. To force a line break inside a paragraph, end a line with two trailing spaces (the original Markdown convention) or, in GFM, a backslash. For a new paragraph, leave a blank line between the two.
Can I use HTML inside Markdown?
Yes, Markdown is a superset of HTML. Inline tags like <span>, <a>, <sub> and <sup> pass through to the rendered output, and Markdown syntax inside them is still recognised. Block-level HTML (<div>, <table>) needs to be separated from surrounding Markdown by blank lines, and Markdown is not processed inside the block. Use this for things Markdown can't express natively: image dimensions (<img width="…">), keyboard chips (<kbd>), or collapsible sections (<details>).
What about tables, footnotes, and task lists?
All three are GFM extensions, not part of the original Markdown spec. Tables use pipe-delimited rows with a hyphen separator row underneath; the simplified parser on this page may render them as plain text. Footnotes ([^1] reference and [^1]: definition) are a GitHub render feature outside the GFM spec proper. Task lists (- [ ] and - [x]) are in GFM. For full coverage of these, paste your file into a CommonMark+GFM-compliant renderer like the GitHub preview itself.
Why is alt text required on images?
Because the alt text is what screen readers announce when they encounter the image, it's the principal accessibility hook for visually-impaired readers.  is technically valid Markdown but useless to a screen reader;  is genuinely descriptive. Skipping alt text or filling it with a filename is one of the most common accessibility failures across web content.
Does anything get sent to a server?
No. The editor parses Markdown to HTML in the browser, the live preview is updated locally, and the auto-save uses your browser's localStorage: a small private store on your device. Nothing leaves the page. The editor works offline once it's loaded.