Skip to content

Comparison

Markdown vs. HTML: wann welches die richtige Antwort ist

Markdown zum Schreiben. HTML zum Rendern. Sie sind keine konkurrierenden Werkzeuge.

By Published

Kurzfassung. Markdown ist ein autorenfreundliches Quellformat, das zu HTML kompiliert. HTML ist das Render-Ziel, das jeder Browser, jedes E-Mail-Programm und jedes CMS letztlich verarbeitet. Schreibt Prosa in Markdown; wechselt inline zu HTML für komplexe Layouts, Formulare und interaktive Elemente.

Markdown und HTML werden oft als Alternativen diskutiert. Sind sie nicht. Markdown ist ein autorenfreundliches Quellformat, das zu HTML kompiliert. HTML ist das universelle Dokument-Render-Format, das Browser, E-Mail-Programme und die meisten Static-Site-Generatoren letztlich verarbeiten. Die Frage ist nicht, welches ihr wählt – sondern in welchem ihr schreiben solltet.

Die wichtigsten Unterschiede

AspektMarkdownHTML
Erstellt2004 (John Gruber)1993 (Tim Berners-Lee)
ZielLeicht zu schreiben, leicht im Klartext zu lesenUniverselle Dokumentstruktur
Typische Syntax für Fett**fett**<strong>fett</strong>
Kompiliert zuHTML(es ist das Ziel)
StandardCommonMark + ErweiterungenWHATWG HTML Living Standard
WerkzeugePandoc, marked, markdown-itJeder Webbrowser

Wann Markdown gewinnt

  • README-Dateien, Doku, Blogposts. Der ganze Sinn. Lesen-während-Schreibens, kein Tag-Lärm, Versionskontroll-Diffs bleiben sauber.
  • Kommentare, Issues, Chat-Nachrichten. GitHub, Discord, Slack, jedes moderne Kollaborationstool akzeptiert Markdown. Fett, Links, Codeblöcke, Listen – universell.
  • Static-Site-Generatoren. Hugo, Jekyll, Next.js MDX, jede moderne Blog-Engine nimmt Markdown-Eingabe.
  • Überall, wo Prosa dominiert. Markdown ist auf „Text mit gelegentlicher Formatierung“ optimiert – genau das Verhältnis, das Autoren tatsächlich brauchen.

Wann HTML gewinnt

  • Alles mit komplexem Layout. Mehrspaltig, Tabellen mit zellgenauem Styling, eigene Positionierung. Markdown kann nicht ausdrücken, was CSS erwartet.
  • Produktive Webseiten. Der Browser rendert nur HTML. Selbst wenn eure Quelle Markdown ist, ist die ausgelieferte Seite HTML.
  • E-Mail. Die meisten E-Mail-Programme rendern HTML; sehr wenige rendern Markdown direkt. Marketing-E-Mails nutzen HTML + Inline-Styles, weil E-Mail-Programme alles Aufwendigere verstümmeln.
  • Interaktive Elemente. Formulare, Skripte, iframes, Accessibility-Attribute (aria-*, role) – reines HTML-Gebiet.

Das Dialekt-Problem

„Markdown“ ist keine einzige Spezifikation. Mehrere inkompatible Dialekte existieren:

  • CommonMark (2014, fortlaufend) – die Standardisierungsbemühung. Streng und vorhersehbar. Die Grundlinie, der die meisten modernen Parser entsprechen.
  • GitHub Flavored Markdown (GFM) – CommonMark plus Tabellen, Durchstreichung, Aufgabenlisten, Autolinks. Der De-facto-Standard für Entwicklerdoku.
  • Pandoc Markdown – erweitert für akademischen und buchlangen Einsatz: Fußnoten, Zitate, Definitionslisten, Mathe über LaTeX.
  • Original John Gruber Markdown (2004) – an Stellen unterspezifiziert. Verschiedene Parser behandeln Randfälle unterschiedlich.

Wenn Portabilität zählt, schreibt nach CommonMark und vermeidet dialektspezifische Erweiterungen.

HTML innerhalb von Markdown

Die meisten Markdown-Parser erlauben es, rohes HTML inline einzustreuen, wenn Markdown nicht ausdrucksstark genug ist. Das ist das pragmatische Ventil – haltet 95 % eures Dokuments in Markdown und wechselt zu HTML für die Tabelle, die Zell-colspans braucht, das iframe, das ein Video einbettet, das Formular.

Manche Parser (StackOverflows etwa) entfernen das meiste HTML aus Sicherheitsgründen. Prüft den Render-Kontext, bevor ihr euch darauf verlasst.

Die pragmatische Regel

  • Schreiben: Markdown. Beginnt immer in Markdown.
  • Lesen: HTML. Browser/E-Mail rendert die HTML-Ausgabe eures Markdowns.
  • Randfälle: bei Bedarf inline zu HTML wechseln.
  • E-Mail-Marketing, komplexe Layouts, produktives Web: direkt HTML.

Zahlen-Fakten

  • Länge der Markdown-Spezifikation: CommonMark 0.31 hat ~70 gedruckte Seiten; der WHATWG HTML Living Standard hat >1.400 Seiten.
  • Tastenanschlag-Verhältnis: für einen typischen 500-Wörter-Artikel mit 6 Links und 3 Überschriften ist die Markdown-Quelle ~620 Zeichen vs. ~1.050 für äquivalentes HTML – grob 40 % weniger Tastenanschläge.
  • Parse-Geschwindigkeit: markdown-it parst ~150 MB/s CommonMark auf einem 2024er-Laptop; moderne HTML-Parser (lxml, html5ever) liegen bei 200–400 MB/s. Beide sind schnell genug, dass Parsing nie der Engpass ist.
  • GFM-Tabellenunterstützung: GitHub Flavored Markdown begrenzt Tabellen auf 64 Spalten; CommonMarks Spezifikation hat überhaupt keine native Tabellensyntax.
  • Verbreitungssignal: ~99 % der READMEs auf GitHub sind Markdown (GitHub gibt an, dass die Zahl 280 Millionen Dateien übersteigt).

Direkte Entscheidungsmatrix

AnwendungsfallWahlWarum
README, Blogpost, Doku-SiteMarkdown (CommonMark)Diff-bar, portabel, autorenorientiert
Marketing-E-MailHTML + Inline-CSSE-Mail-Programme rendern HTML, nicht MD
Mehrspaltige LandingpageHTMLMarkdown kann kein Grid-Layout ausdrücken
GitHub-Issue / PR-KommentarGFMTabellen, Aufgabenlisten, Erwähnungen
Wissenschaftliche Arbeit mit ZitatenPandoc MarkdownFußnoten, BibTeX, Mathe
Static Site (Hugo / Astro / Next MDX)Markdown (oder MDX)Build-Schritt kompiliert zu HTML
Eingebettetes Formular oder iframeHTML inlineMD hat keine Formularsyntax
Chat-Nachricht (Slack, Discord)Markdown-TeilmengeJede Plattform parst ihren eigenen Dialekt

Wo die Tücken lauern

Drei Fehlermodi treten bei Teams immer wieder auf, die Markdown für Dokumentations-Pipelines einführen:

  • Hart umbrochene vs. weich umbrochene Absätze. CommonMark behandelt einen einzelnen Zeilenumbruch innerhalb eines Absatzes als Leerzeichen; GFM folgt derselben Regel, aber manche Alt-Parser (älteres RedCarpet, betagtes Pandoc) behandeln ihn als wörtliches <br>. Die Lösung: brecht innerhalb eines Absatzes nie hart um, außer ihr meint einen Zeilenumbruch.
  • Smart-Quote-Umschreibung. Pandoc, Hugo und manche Jekyll-Plugins schreiben gerade Anführungszeichen stillschweigend in typografische Anführungszeichen um – gut für Prosa, katastrophal in einem nicht eingezäunten Codebeispiel. Nutzt für alles mit Anführungszeichen immer eingezäunte Codeblöcke (dreifache Backticks).
  • Listeneinrückung. CommonMark verlangt, dass verschachtelte Listenelemente um entweder 2 oder 4 Leerzeichen eingerückt werden (passend zum Markeroffset des übergeordneten Listenelements). Tabs rendern parserabhängig unterschiedlich; mischt innerhalb derselben Liste nie Tabs und Leerzeichen.

Quellen

Frequently asked questions

Ist Markdown ein Ersatz für HTML?
Nein – Markdown kompiliert zu HTML. Der Browser rendert weiterhin HTML. Markdown ist ein autorenfreundliches Quellformat; HTML ist das universelle Render-Ziel. Sie ergänzen sich, sie konkurrieren nicht.
In welchem Markdown-Dialekt sollte ich schreiben?
CommonMark für maximale Portabilität. GitHub Flavored Markdown (GFM), wenn euer Publikum auf GitHub liest – es ergänzt Tabellen, Aufgabenlisten und Durchstreichungen. Vermeidet dialektspezifische Erweiterungen, wenn euer Inhalt zwischen Plattformen wandert.
Kann ich HTML innerhalb von Markdown nutzen?
Ja, die meisten Parser akzeptieren rohes HTML inline. Das ist das pragmatische Ventil, wenn Markdown nicht ausdrucksstark genug ist – ein iframe, eine Tabelle mit colspan oder ein Formular einbetten. Manche Plattformen (Stack Overflow) bereinigen HTML aus Sicherheitsgründen; prüft zuerst den Render-Kontext.
Lässt sich Markdown schneller tippen als HTML?
Deutlich – für Prosa mit leichter Formatierung (der 95-%-Fall) braucht Markdown etwa 30–40 % weniger Tastenanschläge als äquivalentes HTML. Der größere Gewinn ist Lesbarkeit: eine Markdown-Quelldatei liest sich als Klartext; eine HTML-Quelldatei als Tag-Suppe.

Related

Published May 15, 2026