Markdown-zu-HTML-Konverter
Markdown mit Live-Vorschau in sauberes HTML umwandeln — Überschriften, Listen, Links, Codeblöcke und mehr, alles im Browser.
1.104 Aufrufe
Wie es funktioniert
Dieser Konverter folgt der CommonMark-Spezifikation — einer präzise definierten Version von Markdown, die die Unklarheiten der ursprünglichen Markdown-Beschreibung von 2004 auflöst (etwa wie verschachtelte Listen mit lockeren Absätzen zusammenspielen oder was passiert, wenn ein Listenzeichen innerhalb eines Zitats steht). Das Parsen läuft in zwei getrennten Durchgängen ab. Der erste Durchgang arbeitet auf Blockebene: Der Rohtext wird allein anhand von Zeilenstruktur und Einrückung — ohne Rücksicht auf den Inhalt der einzelnen Blöcke — in strukturelle Einheiten zerlegt: Absätze, ATX-Überschriften (# bis ######), eingezäunte Codeblöcke, Zitate, geordnete und ungeordnete Listen, horizontale Linien. Der zweite Durchgang arbeitet auf Inline-Ebene: Innerhalb jedes Blocks sucht der Parser nach Hervorhebungszeichen (*kursiv*, **fett**), Inline-Code (`Code`) sowie Link- oder Bildsyntax ([Text](url)) und wandelt sie in die passenden HTML-Tags um. Dieses zweistufige Design erklärt, warum ein Sternchen innerhalb eines eingezäunten Codeblocks unverändert bleibt — Codeblöcke sind bereits im ersten Durchgang vollständig aufgelöst, bevor die Inline-Regeln für Hervorhebungen ihren Inhalt überhaupt erreichen.
Beispiel: Nach ## Release Notes, gefolgt von einer Leerzeile und - **v2.1**: Fehlerbehebungen, erkennt die Blockebene zunächst eine Überschrift und eine Liste mit einem Eintrag; die Inline-Ebene wandelt anschließend **v2.1** innerhalb des <li> in <strong>v2.1</strong> um. Tabellen folgen der GFM-Erweiterung (GitHub Flavored Markdown), die auf CommonMark aufsetzt: eine Kopfzeile, eine ----Trennzeile, deren Doppelpunkt-Platzierung (:--, :-:, --:) die Spaltenausrichtung festlegt, sowie beliebig viele Datenzeilen darunter.
Was zu beachten ist
- Rohes HTML wird escaped, nicht ausgeführt — ein eingefügtes Script-Tag oder ein Inline-Event-Handler wird als sichtbarer Text dargestellt statt ausgeführt, eine bewusste Sicherheitsentscheidung für eingefügten, nicht vertrauenswürdigen Inhalt.
- Lockere und enge Listen verändern die Ausgabe — eine Leerzeile zwischen Listeneinträgen zwingt CommonMark dazu, jeden Eintrag in ein eigenes <p> zu verpacken (eine „lockere" Liste); ohne Leerzeilen bleiben die Einträge einfacher Inline-Inhalt (eine „enge" Liste) — das verändert den vertikalen Abstand in der gerenderten HTML-Ausgabe.
- Sehr tiefe Verschachtelung hat eine praktische Grenze — vier oder mehr Ebenen verschachtelter Listen oder referenzierte Linkdefinitionen sind gültiges CommonMark, aber Grenzfälle, die besser von einem dedizierten Build-Time-Parser als von einer browserbasierten Live-Vorschau bedient werden.
Häufig gestellte Fragen
Werden Tabellen unterstützt?
Ja, über die GFM-Tabellenerweiterung (GitHub Flavored Markdown): eine Kopfzeile, eine --- Trennzeile und beliebig viele Datenzeilen, alle durch Pipes getrennt. Ein Doppelpunkt an einem oder beiden Enden der Trennzellen (:--, :-:, --:) legt links-, zentriert oder rechtsbündige Ausrichtung für diese Spalte fest — das ist eine Erweiterung auf CommonMark, nicht Teil der ursprünglichen Spezifikation.
Warum wird mein HTML-Tag als Text angezeigt statt gerendert zu werden?
Das ist Absicht. Rohes HTML in der Eingabe wird escaped statt unverändert in die Ausgabe übernommen, sodass ein eingefügtes <script>-Tag oder ein onclick-Attribut als reiner Text erscheint statt ausgeführt zu werden — genau das macht das Einfügen nicht vertrauenswürdiger Inhalte sicher. Schreiben Sie das Äquivalent stattdessen in Markdown-Syntax, oder entfernen Sie das Escaping später manuell, wenn Sie der Quelle vollständig vertrauen.
Folgt der Zeilenabstand den Markdown-Regeln?
Ja: Eine Leerzeile zwischen Textzeilen trennt Absätze, und eine Zeile, die vor dem Zeilenumbruch mit zwei Leerzeichen endet, erzeugt einen <br> statt eines Absatzumbruchs. Ein einzelner Zeilenumbruch mitten in einem Absatz wird einfach zur selben Zeile zusammengefügt, genau wie CommonMark es vorschreibt — das stolpert häufig Nutzer, die von reinen Text-Editoren kommen, in denen jeder Zeilenumbruch bedeutsam ist.
Warum sieht die Formatierung in einer verschachtelten Liste oder einem Codeblock manchmal unerwartet aus?
Weil das Parsen zweistufig abläuft: Die Blockstruktur (Listen, Codezäune, Zitate) wird zuerst rein anhand von Einrückung und Zeilenzeichen aufgelöst, bevor die Inline-Formatierung (fett, kursiv, Links) innerhalb jedes Blocks angewendet wird. Inhalt in einem eingezäunten Codeblock wird vom Inline-Durchgang nie berührt, weshalb **dies** dort als reiner Text stehen bleibt statt fett zu werden — das ist erwartetes CommonMark-Verhalten, kein Fehler.
Was ist der Unterschied zwischen dem Kern von CommonMark und den „GitHub Flavored"-Funktionen?
Der CommonMark-Kern definiert Überschriften, Hervorhebungen, Listen, Zitate, Codeblöcke und Links präzise. Tabellen, Durchgestrichenes (~~Text~~) und Aufgabenlisten-Kästchen ([ ] / [x]) sind GFM-Erweiterungen, die darauf aufsetzen — von vielen Konvertern wie diesem hier breit unterstützt, aber nicht in jeder streng CommonMark-konformen Anwendung garantiert, in die Sie die Ausgabe später einfügen könnten.
Ähnliche Tools
Problem melden
Markdown-zu-HTML-Konverter
Kommentare
Noch keine Kommentare — schreiben Sie den ersten!