Markdown zu HTML mit Live-Erklärer und GFM↔CommonMark-Vergleich
Markdown zu HTML konvertieren und sehen, was jedes Zeichen produziert - mit Live-Erklärer pro Element und sichtbarem GFM-vs-CommonMark-Vergleich.
Markdown-zu-HTML-Konverter gibt es reichlich - Markdown rein, HTML raus, fertig. Was beim Lernen oder Debuggen fehlt, ist die Erklärung dazu: warum genau dieses HTML entsteht, und wo GFM und CommonMark wirklich auseinandergehen. Beides findest du hier - die Spec-Regel zu jedem Element, sobald du mit der Maus drauf zeigst, und ein Flavor-Toggle, mit dem du zwischen GFM und CommonMark wechselst.
Markdown zu HTML
Hover ein Element rechts - das HTML-Element leuchtet auf, mit Spec-Regel daneben.
Was funktioniert
- fett und kursiv
durchgestrichen(nur GFM)- Inline-
codeund Code-Blöcke
const greeting = "Hallo, Welt";
console.log(greeting);
Markdown ist eine Spec, kein einzelnes Tool. CommonMark und GFM rendern manche Sachen unterschiedlich.
| Feature | CommonMark | GFM |
|---|---|---|
| Tabellen | ❌ | ✅ |
| Strikethrough | ❌ | ✅ |
| Autolinks | ❌ | ✅ |
Mehr unter https://spec.commonmark.org - autolink-Test.
Was rendert anders
7 Elemente in deinem Markdown würde CommonMark nicht rendern - sie blieben Markdown-Text.
Klick eine Kachel - die betroffenen Zeilen leuchten im Editor auf.
Läuft komplett im Browser. Dein Markdown wird nicht hochgeladen, gespeichert oder analysiert.
Wie konvertiert man Markdown zu HTML?
Markdown gibst du links ein, das HTML steht rechts - ohne Klick auf "Konvertieren" und ohne Wartezeit. Wenn du in der Vorschau auf ein Element zeigst, blendet der Live-Erklärer ein, welcher Markdown-Token welches HTML-Tag erzeugt hat, dazu die passende Regel aus der Spec. Drei Copy-Buttons darunter liefern semantisches HTML, Inline-Styles für E-Mails oder ein Fragment ohne Wrapper.
Konkret sind das vier Handgriffe:
- Markdown links eingeben oder einfügen.
- Flavor wählen - GFM (Standard) oder CommonMark.
- Mit der Maus über ein Element in der Vorschau fahren, um die Spec-Regel abzulesen.
- Auf Semantisch, Inline-styled oder Fragment klicken, je nach Ziel.
Die Konvertierung läuft komplett im Browser. Dein Markdown verlässt die Seite nicht.
Was ist der Unterschied zwischen GFM und CommonMark?
CommonMark ist die strenge Basis-Spec, GFM (GitHub Flavored Markdown) ist CommonMark plus eine Handvoll Erweiterungen, die GitHub für sein eigenes Rendering eingeführt hat. Jedes GFM-Dokument ist auch gültiges CommonMark, aber CommonMark allein kann ein paar GFM-Konstrukte schlicht nicht darstellen. In diesem Konverter sind fünf davon spürbar.
| Konstrukt | CommonMark | GFM | Anmerkung |
|---|---|---|---|
| Tabellen | ❌ | ✅ | GFM-Erweiterung |
Strikethrough (~~text~~) | ❌ | ✅ | GFM-Erweiterung |
| Einfache URLs als Link | ❌ | ✅ | Linkify - <https://…>-Autolinks gehen in beiden |
| Task-Listen | ❌ | ✅ | GFM-Erweiterung |
| Emoji-Shortcodes | ❌ | ✅ | Plugin (markdown-it-emoji), nicht Teil der GFM-Spec |
Den Toggle oben anklicken, und du siehst den Wechsel direkt im Output. Unter dem Konverter listet "Was rendert anders" nur die Zeilen auf, die in deinem aktuellen Markdown zwischen den Flavors abweichen - kein theoretischer Überblick, sondern die konkrete Differenz für deinen Text.
Warum erzeugt _dateiname_ ein <em>?
Markdown behandelt Underscores wie Sternchen als Zeichen für Hervorhebung: _kursiv_ und *kursiv* ergeben beide <em>kursiv</em>. Wenn dein Dateiname mit einem Underscore beginnt UND endet, liest der Parser die beiden Underscores als Klammern um eine Hervorhebung, und aus dem Dateinamen wird Kursivschrift. Ein klassischer Stolperstein, gerade bei Pfaden, Variablennamen oder Datei-Endungen.
Der Unterschied liegt in der Position der Underscores. CommonMark trennt Intra-Word- und Edge-Underscores: datei_name_v2 bleibt unverändert Text, weil die Underscores zwischen Buchstaben oder Zahlen stehen. Bei _dateiname_ stehen sie an den äußeren Rändern - genau dort löst Markdown Hervorhebung aus.
Drei Auswege:
- Backslash davor:
\_dateiname\_rendert als_dateiname_, die Unterstriche bleiben sichtbar. - Inline-Code:
`_dateiname_`rendert in Monospace, das Markdown wird gar nicht erst geparst. - Bindestriche statt Underscores, wenn möglich -
-dateiname-umgeht die Regel komplett.
Zeige in der Vorschau auf _dateiname_, und die genaue Regel erscheint im Erklärer-Streifen direkt darüber.
Sauberes HTML für CMS, E-Mail oder eingebettete Inhalte
Der Standard-Output ist sauberes, semantisches HTML - das passt für die meisten Ziele: CMS, statische Seite, Blog-Engine. Zwei Sonderfälle brauchen etwas anderes. E-Mail-Clients ignorieren externes CSS und brauchen Style-Attribute direkt am Element. Eingebettete Schnipsel sollten kein eigenes <html> oder <body> mitbringen, das mit dem umgebenden Layout streiten würde.
Genau dafür sitzen drei Copy-Buttons unter dem Konverter - statt einem einzigen Knopf, der dir verschweigt, was er kopiert:
- Semantisch. Saubere Tags, keine Inline-Styles. Standard für CMS-Editoren wie WordPress, Ghost oder Notion, dazu Hugo, Eleventy, MDX.
- Inline-styled. Style-Attribute auf jedem
<h1>,<p>,<pre>,<table>- übersteht Gmail, Outlook und Apple Mail. Die Auswahl bleibt konservativ: keine eigenen Schriften, keine CSS-Variablen. - Fragment. Ohne
<html>,<body>,<head>- nur der Inhalt, fertig zum Einfügen in einen vorhandenen Wrapper.
Faustregel: CMS und Static-Site-Generatoren nehmen Semantisch, HTML-Newsletter nehmen Inline-styled, eingebettete Snippets nehmen Fragment.
Häufige Fragen
Welche Markdown-Konstrukte werden unterstützt?
Alle CommonMark-Block- und Inline-Konstrukte ausser rohem HTML - eingebettete <script>- oder <div>-Tags werden escaped statt durchgereicht (Safe-by-Default). Dazu die GFM-Erweiterungen Tabellen, Strikethrough (~~weg~~), Linkify für einfache URLs, Task-Listen (- [ ] und - [x]) sowie Emoji-Shortcodes (:sparkles:, ein markdown-it-emoji-Plugin, das nicht zur GFM-Spec gehört). Fenced Code-Blöcke bekommen Syntax-Highlighting per highlight.js für JS/TS, HTML/XML, CSS, JSON, Bash, Python, Go, Rust, YAML und Markdown. Unbekannte Sprachhinweise rendern als reine Code-Blöcke ohne Highlighting.
Wird mein Markdown irgendwo gespeichert?
Nein. Die Konvertierung läuft komplett im Browser, dein Markdown verlässt die Seite nicht. Beim Klick auf Teilen wird der Inhalt base64-kodiert in den Link gepackt (Gesamt-URL gedeckelt auf 2000 Zeichen), aber das passiert nur durch deinen Klick.
Warum sind meine Tabellen plötzlich nur Text?
Vermutlich steht der Flavor-Toggle auf CommonMark. Tabellen gehören zur GFM-Erweiterung, im reinen CommonMark bleiben die Pipes als Text stehen. Schalte oben auf GFM, derselbe Quelltext rendert dann als Tabelle.
Kann ich auch HTML zurück in Markdown konvertieren?
Noch nicht. HTML zu Markdown bekommt ein eigenes Werkzeug - die Eingabe-Formen sind zu verschieden, um sauber in einer Seite zu wohnen. Sobald das Tool live ist, landet der Link hier.
Welche Spec-Version nutzt der Konverter?
markdown-it@14. Die CommonMark-Compliance richtet sich nach der 0.30-Spec. Die aktuelle Spec-Version ist 0.31.2; die zwischen 0.30 und 0.31.2 ergänzten Konstrukte rendert markdown-it identisch. Die GFM-Teile decken die Erweiterungen aus dem GitHub Flavored Markdown Spec (0.29-gfm) ab: Tabellen, Strikethrough, Linkify für einfache URLs, Task-Listen.