Markdown zu HTML Konverter

So verwendest du diesen Konverter

1. Füge dein Markdown ein. Das Werkzeug akzeptiert CommonMark plus die häufigsten GFM-Erweiterungen, Tabellen, abgegrenzte Codeblöcke mit Sprachhinweisen, Durchstreichungen, Autolinks und Aufgabenlisten-Elemente.
2. Beobachte die Live-Umwandlung. Der rechte Bereich zeigt die rohe HTML-Ausgabe, während du tippst; der Vorschaubereich darunter rendert sie visuell.
3. Kopiere das HTML. Verwende die Schaltfläche HTML kopieren, um die Ausgabe bereit zum Einfügen in dein CMS, deinen E-Mail-Client, deine Static-Site-Generator-Vorlage oder anderswo zu erhalten, das HTML akzeptiert.

Eine kurze Geschichte von Markdown

Markdown wurde von John Gruber, dem Autor des Daring-Fireball-Weblogs, mit erheblichem Design-Feedback von Aaron Swartz geschaffen. Die erste öffentliche Version, 1.0, wurde am 9. März 2004 auf Grubers Seite angekündigt; Version 1.0.1, die kanonische Referenzversion, folgte am 17. Dezember 2004 und ist immer noch die Version, die von daringfireball.net/projects/markdown verlinkt wird. Markdown war von Anfang an zwei Dinge gleichzeitig: eine Klartext-Formatierungssyntax und das ursprüngliche Perl-Skript, das es in HTML konvertierte. Grubers erklärtes Ziel war, dass der Quelltext lesbar als solcher sein sollte, ein Markdown-Dokument, das in einem Klartext-Editor geöffnet wird, sollte wie eine durchdachte formatierte E-Mail aussehen, nicht wie eine Tag-Suppe. Diese Lesbarkeitsbeschränkung ist die philosophische Linie, die Markdown von XML-basierten Formaten und schwerer Auszeichnung wie LaTeX trennt, und es ist der Grund, warum jede spätere Erweiterung sich rechtfertigen musste in Bezug darauf, wie stark sie die Quelle stört. Aaron Swartz hatte zuvor eine verwandte leichtgewichtige Auszeichnung namens atx (2002) geschrieben, die zum jetzt vertrauten #- und ##-Überschriftenstil beigetragen hat, manchmal in Parser-Spezifikationen immer noch "atx-Stil-Überschriften" genannt.

CommonMark, die Unterspezifikation beheben

Grubers ursprüngliche Syntaxbeschreibung von 2004 war bekanntermaßen informell, ein Prosa-Dokument mit Beispielen, keine Grammatik. Sie ließ Dutzende von Grenzfällen unspezifiziert, und Gruber veröffentlichte nie einen Referenz-Parser außer seinem Perl-Skript, dessen Verhalten idiosynkratisch auf Arten war, die andere Implementierer entweder kopieren oder überschreiben mussten. Das Ergebnis bis zu den frühen 2010er Jahren war, dass GitHub, Reddit, Stack Overflow, Pandoc und der Discount-C-Parser dieselbe Markdown-Quelle leicht unterschiedlich renderten. 2012 begannen Stack-Overflow-Mitbegründer Jeff Atwood und Pandoc-Autor John MacFarlane mit dem Bemühen, eine echte, testbare Spezifikation zu schreiben. Das Projekt wurde im September 2014 öffentlich als "Standard Markdown" gestartet; innerhalb von Tagen widersprach Gruber dem Namen in privater E-Mail, Atwood schrieb einen öffentlichen Beitrag, der die Änderung erklärte, und das Projekt wurde in "CommonMark" umbenannt. Die erste nummerierte Veröffentlichung kam am 25. Oktober 2014. Die aktuelle veröffentlichte Version ist CommonMark 0.31.2, veröffentlicht am 28. Januar 2024. Die CommonMark-Spec ist ungewöhnlich, da sie selbst ein CommonMark-Dokument ist, mit über 600 ausführbaren Testfällen inline; ein Parser beansprucht Konformität, indem er diese Tests besteht. GitHub Flavored Markdown (GFM), die formale Spec in Version 0.29-gfm vom 6. April 2019, definiert fünf Erweiterungen über CommonMark: Tabellen, Aufgabenlisten-Elemente, Durchstreichung, Autolinks für nackte URLs und nicht erlaubtes rohes HTML (eine Sicherheitsbeschränkung, die gefährliche Tags aus vom Autor gelieferten HTML entfernt).

Die wichtigsten Parser

marked.js wurde 2011 von Christopher Jeffrey erstellt und wird seit 2018 von der markedjs GitHub-Organisation gepflegt, ein einmal durchlaufendes Lexer-dann-Parser-Design, das rohe Geschwindigkeit priorisiert; ~36k Sterne und das meistgesternte Markdown-Projekt auf GitHub. Es ist der Parser, den dieses Werkzeug für die Konvertierung verwendet. markdown-it wurde 2014 von Vitaly Puzrin und Alex Kocharin gestartet und wirbt mit 100% CommonMark-Konformität mit optionalen GFM-Schaltern plus einem aggressiven Plugin-Ökosystem (markdown-it-footnote, markdown-it-emoji, markdown-it-attrs, markdown-it-anchor und mehrere hundert andere). Es ist der Parser, der von VS Codes eingebauter Markdown-Vorschau, GitLabs Web-UI und Eleventy verwendet wird. remark / unified.js ist kein einzelner Parser, sondern ein Baum-Transformations-Framework, das unified-Kollektiv definiert eine abstrakte Syntaxbaum-Spec namens mdast (Markdown AST); remark parsed Markdown in mdast, Plugins manipulieren den Baum, und remark-rehype konvertiert mdast in hast (HTML AST) zur Ausgabe. Langsamer als marked, aber viel komponierbarer; bemerkenswerte Nutzer sind Prettier, Gatsby, MDN und der alex-Inklusiv-Sprach-Linter. Pandoc, am 10. August 2006 von John MacFarlane veröffentlicht, ist der universelle Dokumentenkonverter, in Haskell geschrieben, parst etwa 30 Eingabeformate, rendert in etwa 40 Ausgabeformate; allgegenwärtig in akademischer und technischer Veröffentlichung.

Die MD-zu-HTML-Pipeline, mechanisch

Ein Markdown-Parser arbeitet typischerweise in zwei Durchgängen. Block-Level-Parsing teilt die Eingabe in Blockstrukturen auf, Absätze, Überschriften, Listen, Code-Zäune, Blockzitate, horizontale Regeln, Tabellen. Blockgrenzen werden durch Leerzeilen und Einrückung bestimmt; sie richtig zu treffen ist das meiste von dem, was einen CommonMark-Parser korrekt macht. Inline-Parsing durchläuft dann den Inhalt jedes Blocks und passt Inline-Syntax an: Hervorhebung (*kursiv*, **fett**), Links ([Text](URL)), Inline-Code-Spans (`Code`), Bilder (![Alt](URL)), Durchstreichung (~~Text~~ in GFM) und explizite Autolinks (<https://example.com>). Inline-Hervorhebungsparsing ist der knifflichste Teil jeder Markdown-Spec, CommonMark widmet mehrere Seiten der Spec und Dutzende von Testfällen der Spezifikation, wann *foo*bar* <em>foo</em>bar* versus *foo<em>bar</em> produzieren sollte. Der Parser rendert dann jedes Token als das entsprechende HTML-Element und verkettet die Ergebnisse. Hübsches Drucken, Einrückung und Code-Block-Syntax-Highlighting werden von den Rendering-Optionen darüber gelegt.

Warum überhaupt MD in HTML umwandeln?

• CMS-Importe. Viele Headless-CMS (Contentful, Sanity, Wagtail, Ghost) akzeptieren HTML, aber kein Markdown. Das Verfassen in Markdown und Konvertieren einmal zum Veröffentlichungszeitpunkt hält die Bearbeitungserfahrung angenehm.
• E-Mail-Komposition. E-Mail-Clients rendern HTML; die meisten rendern kein Markdown. Newsletter-Plattformen (Mailchimp, ConvertKit, Substack) akzeptieren typischerweise in ihren Editor eingefügtes HTML. Konvertiere deinen Entwurf, füge ein, sende.
• Blogbeitrag-Entwürfe. Einige Legacy-WordPress-Installationen ohne das Markdown-Plugin erfordern HTML im Beitragstext; einige Shopify- und Webflow-Shop-Seiten nehmen HTML in ihren Rich-Text-Feldern auf.
• Static-Site-Generator-Schnipsel. Wenn du einen Inline-HTML-Block für einen Hugo-Shortcode, eine Eleventy-Vorlage oder eine Next.js-MDX-Datei brauchst, ist die Konvertierung von Markdown in ein einzelnes HTML-Fragment schneller als das Kämpfen mit der eigenen Konvertierungspipeline des SSG.
• Geteilte gerenderte Notizen. Das Einfügen von "gerendertem" Markdown in Slack, Notion, Linear, ClickUp oder andere Rich-Text-Ziele möchte manchmal HTML in der Zwischenablage statt rohem Markdown.
• Dokumentation archivieren. Das gerenderte HTML neben der Markdown-Quelle zu speichern bedeutet, dass dein Archiv in einem Browser ohne Parser menschlich lesbar ist, nützlich für die Langzeitarchivierung.

Wissenswerte Ausgabeoptionen

Verschiedene nachgelagerte Verwendungen wollen verschiedene Dinge vom konvertierten HTML. Vollständiges Dokument vs. Fragment. Ein vollständiges HTML-Dokument enthält <!DOCTYPE html>, <html>, <head> mit Metadaten und einen <body>-Wrapper, angemessen, wenn du die Datei als .html speichern und in einem Browser öffnen wirst. Ein Fragment ist nur der Body-Inhalt, kein Wrapper, angemessen, wenn du in ein CMS-Feld einfügen wirst, das bereits die Dokumentstruktur bereitstellt. Dieses Werkzeug gibt standardmäßig Fragmente aus; wickle mit deiner eigenen Boilerplate ein, wenn du ein vollständiges Dokument brauchst. Bereinigung. Standardmäßig lassen Markdown-Parser rohes HTML unverändert durch, also wenn deine Quelle <script>alert(1)</script> enthält, wird dieses Skript-Tag in der Ausgabe erscheinen. Für Dokumente, die in ein Multi-User-System gehen, lasse die Ausgabe durch DOMPurify (Cure53, gestartet Februar 2014) laufen, bevor du in das DOM injizierst. Für einmalige persönliche Verwendung ist die rohe Ausgabe in Ordnung. Überschriften-IDs. Die Generierung von id-Attributen auf Überschriften (aus dem Überschriftentext sluggifiziert) lässt dich ein Inhaltsverzeichnis mit Anker-Links erstellen. Der exakte Slug-Algorithmus unterscheidet sich zwischen Plattformen, GitHub verwendet eine Regel, MkDocs eine andere, marked.js eine dritte, sodass Anker-Links brechen können, wenn Inhalte zwischen Systemen wandern. Harte Zeilenumbrüche. CommonMark erfordert entweder zwei abschließende Leerzeichen am Ende einer Zeile oder einen Backslash, um einen <br> zu erzwingen; einige Plattformen (Discord, GitHub-Issues) behandeln einzelne Newlines als Umbrüche. Die Wahl hängt vom erwarteten Stil deiner Quelle ab.

Häufige Fallstricke

• Smart-Quote-Umwandlung. Einige Parser (oder Nachbearbeitungsschichten wie Grubers eigene SmartyPants) ersetzen gerade Anführungszeichen standardmäßig durch geschwungene typografische Anführungszeichen. Wenn du gerade Anführungszeichen erhalten musst (weil deine Ausgabe als Code geparst wird), überprüfe, dass diese Transformation ausgeschaltet ist.
• Listen-Marker-Whitespace-Empfindlichkeit. Das Mischen von - und * und + in derselben Liste, das Einrücken von Listenfortsetzungsabsätzen um weniger als der Marker erfordert, oder das Setzen einer Leerzeile zwischen Listenelementen kann eine enge Liste in eine lose Liste verwandeln (jedes Element in <p>-Tags eingewickelt). Der visuelle Unterschied in der Ausgabe ist dramatisch.
• Übermäßiger Eifer des Autolinks. Autolinking im GFM-Stil verwandelt jede nackte URL in einen Link, was normalerweise das ist, was du willst, aber URLs mit Klammern (Wikipedia-URLs insbesondere) oder nachfolgender Interpunktion verstümmeln kann.
• Tabellen, die Escape benötigen. Pipe-Zeichen innerhalb von Tabellenzellen müssen als \| escaped werden, sonst werden sie als Spaltentrennzeichen gelesen. Erwischt jeden, der versucht, ein einzeiliges Codebeispiel in eine Zelle zu setzen.
• Gemischtes Markdown und HTML. Markdown wurde entwickelt, um beliebiges HTML durchzulassen, also funktioniert das Einfügen eines <div class="callout"> in eine Markdown-Datei. Aber sobald du Markdown-Syntax innerhalb eines HTML-Blocks setzt, divergieren Parser: CommonMark behandelt die meisten HTML-Blöcke als opak; Markdown Extra führte markdown="1" ein, um sich für verschachteltes Parsing anzumelden.
• Überschriften-IDs zwischen Plattformen. Verschiedene Slugify-Algorithmen produzieren verschiedene Anker-Fragmente für dieselbe Überschrift; intra-Dokument-Links können brechen, wenn Inhalt zwischen Systemen wandert.

Dieses Werkzeug vs. der Markdown-Vorschauer

Absolutool liefert zwei verwandte Werkzeuge, die sich auf denselben Parser überlappen. Der Markdown-Vorschauer ist für Live-Bearbeitung, schreibe Markdown links, sieh die gerenderte visuelle Ausgabe rechts, kein Konzept von "der HTML-Ausgabe". Dieser Markdown-zu-HTML-Konverter ist für einmalige Konvertierung, füge Markdown ein, kopiere rohes HTML, füge in dein CMS oder deinen E-Mail-Client ein. Verwende den Vorschauer, wenn du entwirfst und visuelles Feedback brauchst; verwende diesen Konverter, wenn du fertiges Markdown hast und HTML brauchst, das du anderswohin transportieren kannst. Beide Werkzeuge verwenden marked.js unter der Haube und akzeptieren denselben CommonMark + GFM-Dialekt, sodass das Konvertierungsverhalten zwischen ihnen identisch ist.

Datenschutz: Warum reiner Browser hier wichtig ist

Entwürfe unveröffentlichten Schreibens, in Arbeit befindliche Blogbeiträge, interne Dokumentation, Kunden-Deliverables unter NDA, Manuskriptkapitel, akademische Aufsätze, sind genau die Art von Text, den du nicht auf einen Drittanbieter-Service hochladen möchtest. Serverseitige Markdown-Konverter erfordern das Senden des gesamten Dokuments an einen entfernten Endpunkt, was bedeutet, dass es in den Logs des Servers landet, möglicherweise in einem CDN-Cache, möglicherweise in einer Analytics-Pipeline, möglicherweise in einem Backup. Für veröffentlichten Text ist das Problem strittig. Für Entwurfsarbeit ist die Architektur wichtig. Dieses Werkzeug führt die gesamte Pipeline in deinem Browser über JavaScript und marked.js aus. Das Markdown überquert nie das Netzwerk, verifiziere im Netzwerk-Tab von DevTools, während du tippst, oder nimm die Seite offline (Flugmodus), nachdem sie geladen ist, und bestätige, dass der Konverter immer noch funktioniert. Sicher für vertrauliche Entwürfe, Kunden-Deliverables, Manuskriptkapitel unter NDA, interne Memos oder alles andere, das du nicht auf der Festplatte eines Fremden kopiert haben möchtest.

Häufig gestellte Fragen

Welchen Markdown-Dialekt unterstützt dieser Konverter?

CommonMark mit den häufigsten aktivierten GFM-Erweiterungen, Tabellen (pipe-getrennt mit optionaler :-Ausrichtung), abgegrenzte Codeblöcke mit Sprachhinweisen, Durchstreichung via ~~Text~~, Autolinks für nackte URLs und Aufgabenlisten-Elemente via [ ] und [x]. Überschriften, fett, kursiv, Links, Bilder, Listen, Blockzitate, horizontale Regeln und Inline-Code funktionieren alle wie auf GitHub erwartet. Der Renderer ist marked.js, derselbe Parser, den der Markdown-Vorschauer verwendet.

Unterstützt dies GitHub Flavored Markdown (GFM)?

Ja, Tabellen mit Pipes, abgegrenzte Codeblöcke mit Sprachhinweisen, Aufgabenlisten, Autolinks und Durchstreichung funktionieren alle. Wenn eine GFM-Erweiterung nicht rendert, überprüfe doppelt, ob die Eingabe den CommonMark/GFM-Syntaxregeln folgt: Leerzeilen um Blockelemente, übereinstimmende Backtick-Zählungen bei abgegrenzten Codeblöcken, genau zwei abschließende Leerzeichen (oder ein Backslash) für harte Zeilenumbrüche. Die häufigste Ursache für "GFM funktioniert nicht" ist ein Editor, der abschließenden Whitespace beim Speichern entfernt, was die Hard-Break-Syntax tötet.

Wird die Ausgabe auf GitHub gleich aussehen?

Das strukturelle HTML, Absätze, Listen, Tabellen, Überschriften, wird für jede Eingabe übereinstimmen, die gültiges CommonMark + GFM ist. Zwei Schichten werden sich unterscheiden. GitHub wendet sein eigenes CSS-Theme und Syntax-Highlighting an, sodass Farben, Schriftarten und Abstände unterschiedlich aussehen werden. GitHub legt auch Nachbearbeitung über die Spec, Emoji-Shortcodes (:smile:), @user-Erwähnungen, #issue-Auto-Linking, repository-relative Bildpfade, die kein spezifikationskonformer Konverter reproduziert. Das HTML, das dieses Werkzeug ausgibt, ist strukturell portabel; das visuelle Erscheinungsbild hängt vom CSS am Ziel ab.

Soll ich die Ausgabe vor der Veröffentlichung sanitieren?

Wenn die Quelle benutzergelieferten Inhalt enthalten könnte, ja. Markdown-Parser lassen rohes HTML unverändert durch, also wird eine Quelle, die <img src=x onerror="alert(1)"> enthält, dieses Tag in der Ausgabe produzieren. Für Multi-User-Systeme lasse die Ausgabe durch DOMPurify (Cure53, Februar 2014, der De-facto-JavaScript-Sanitizer) laufen, bevor du in das DOM injizierst. Für einmalige persönliche Verwendung, wo die Quelle dein eigenes Schreiben ist, ist dies kein Problem, das Schlimmste, was du deiner eigenen Seite antun kannst, ist dein eigenes HTML einzufügen.

Kann ich ein vollständiges HTML-Dokument mit Head und Body erhalten?

Derzeit gibt dieses Werkzeug nur das Body-Fragment aus, das konvertierte Markdown in semantische HTML-Tags eingewickelt, aber nicht in ein vollständiges <html>/<head>/<body>-Dokument. Um als eigenständige .html-Datei zu speichern, wickle die Ausgabe selbst ein: <!DOCTYPE html><html><head><meta charset="utf-8"><title>...</title></head><body>[Fragment]</body></html>. Oder verwende Pandoc mit dem --standalone-Flag für vollständig eigenständige Ausgabe mit vorlagengetriebenem CSS.

Wird mein Markdown irgendwohin gesendet?

Nein. Die Konvertierung läuft vollständig in deinem Browser über marked.js. Das Markdown, das du einfügst, überquert nie das Netzwerk, verifiziere im Netzwerk-Tab von DevTools, während du tippst, oder nimm die Seite offline (Flugmodus), nachdem sie geladen ist, und bestätige, dass der Konverter immer noch funktioniert. Sicher für vertrauliche Entwürfe, Kunden-Deliverables unter NDA, Manuskriptkapitel oder jeden Text, den du nicht auf der Festplatte eines Fremden kopiert haben möchtest.

Verwandte Tools