Kostenloser Markdown-Editor
Schreiben Sie Markdown mit Live-HTML-Vorschau.
So funktioniert es
- Tippen oder fügen Sie Markdown-Text in das linke Feld. Das rechte Feld zeigt die HTML-Vorschau in Echtzeit.
- Nutzen Sie die Symbolleisten-Buttons, um schnell Formatierungen einzufügen (fett, kursiv, Überschriften, Links usw.).
- Sehen Sie unter dem Editor Wort-, Zeichen- und Zeilenanzahl.
- Laden Sie Ihr Markdown als .md-Datei herunter oder kopieren Sie die HTML-Ausgabe.
Häufige Fragen
Unterstützt dieser Editor Standard-Markdown-Syntax?
Ja. Er unterstützt Überschriften, Fett, Kursiv, Links, Bilder, Codeblöcke, Listen, Zitate und horizontale Linien. Ein vereinfachter Markdown-Parser rendert in Echtzeit zu HTML.
Kann ich meine Arbeit speichern?
Der Editor speichert Ihren Text während der Bearbeitung automatisch im Browserspeicher. Verwenden Sie .md herunterladen, um ihn als Datei auf Ihrem Computer zu speichern.
Wie füge ich einen Link oder ein Bild ein?
Verwenden Sie die Symbolleisten-Buttons. Für Links tippen Sie [Text](URL). Für Bilder verwenden Sie . Die Vorschau aktualisiert sich sofort.
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.