KeroTools

Markdown zu HTML mit Live-Vorschau

Wandeln Sie Markdown-Text in sauberes HTML um, mit einer Vorschau, die sich beim Tippen aktualisiert.

Eingabe
0 Zeichen
HTML

Ihr Dokument bleibt auf dem Gerät

Nichts, was später zu löschen wäre

Sicher für interne Dokumentation

Läuft in jedem modernen Browser

So funktioniert es

  1. 1

    Markdown einfügen

    Eine README, eine Dokumentationsseite, einen Beitrag oder Notizen, die Sie als HTML brauchen.

  2. 2

    Vorschau prüfen

    Bestätigen Sie, dass die Struktur wie beabsichtigt herauskam, bevor Sie das Markup ansehen.

  3. 3

    HTML kopieren

    Nehmen Sie es in ein CMS, eine E-Mail-Vorlage, eine statische Seite oder eine Dokumentationsseite.

Warum dieses Tool

CommonMark plus GitHub-Erweiterungen

Tabellen, Durchstreichung, Aufgabenlisten und automatische Links — der Dialekt, in dem das meiste Markdown wirklich geschrieben wird.

Vorschau und Markup zugleich

Sehen Sie das gerenderte Ergebnis und das erzeugte HTML, um beides zu prüfen, bevor Sie eines einfügen.

Semantische Ausgabe

Echte Überschriften, Listen und Tabellen statt einer Wand gestylter divs — das Markup bedeutet etwas.

Zeilenumbruchverhalten nach Wahl

Entscheiden Sie, ob ein einzelner Umbruch die Zeile bricht oder sich dem Absatz anschließt — die Einstellung, die alle suchen.

Nichts wird hochgeladen

Die Umwandlung geschieht in Ihrem Browser — unveröffentlichte Dokumentation erreicht nie einen Server.

Kostenlos, ohne Konto

Keine Anmeldung, kein Wasserzeichen, keine Obergrenze für die Menge.

Es gibt kein „das Markdown“ — es gibt mehrere

Das ist die Tatsache hinter den meisten Überraschungen. Die ursprüngliche Beschreibung von 2004 bestand aus einem kurzen Dokument und einem Perl-Skript, ohne formale Grammatik und ohne Testsuite, was sehr vieles wirklich undefiniert ließ. Implementierungen füllten die Lücken verschieden, sodass dieselbe Eingabe je nach verwendetem Werkzeug andere Ausgaben lieferte. CommonMark existiert genau dafür: eine präzise Spezifikation mit Konformitätssuite, und die meisten ernsthaften Parser zielen heute darauf. Doch CommonMark lässt bewusst Dinge aus, die ständig gebraucht werden, weshalb GitHub Flavored Markdown Tabellen, Durchstreichung, Aufgabenlisten und automatische Links obendrauf setzt. Praktisch heißt das: Ein Dokument mit einer Tabelle erscheint auf GitHub als Tabelle und in einem strikten CommonMark-Parser als wörtliche Striche. Bevor Sie Ihr Markdown beschuldigen, prüfen Sie, welchen Dialekt das Ziel spricht.

Ein einzelner Zeilenumbruch ist kein Zeilenumbruch

Das ist das Verhalten, das mehr Menschen verwirrt als alles andere zusammen, und es ist kein Fehler. Markdown behandelt aufeinanderfolgende Zeilen als einen Absatz und verbindet sie mit einem Leerzeichen, denn das Format wurde so entworfen, dass das manuelle Umbrechen eines Absatzes im Editor die Ausgabe nicht ändert. Zwei getrennt geschriebene Adresszeilen erscheinen daher in einer Zeile. Das klassische Mittel sind zwei Leerzeichen am Zeilenende — eine wirklich schlechte Konvention, weil sie unsichtbar ist und Editoren sie entfernen. Ein Backslash am Zeilenende leistet in CommonMark dasselbe und ist immerhin sichtbar. Und eine Leerzeile beginnt einen neuen Absatz, was meist gemeint war. GitHub hat die Voreinstellung in Kommentarfeldern geändert, sodass ein Umbruch dort bricht — deshalb verhält sich derselbe Text in einem Ticket anders als in einer README.

Markdown lässt HTML absichtlich durch, und das ist eine Sicherheitsentscheidung

Rohes HTML in Markdown ist ein Merkmal, kein Versehen: Der ursprüngliche Entwurf nahm an, man wechsle zu HTML, sobald Markdown nicht ausreicht. Das heißt, ein Markdown-zu-HTML-Wandler darf laut Spezifikation ein `<script>`-Tag unverändert in seine Ausgabe durchreichen. Für eigene Dokumente ist genau das erwünscht. Für alles, was Nutzer eingereicht haben — einen Kommentar, eine Bewertung, eine Profilbeschreibung, ein Support-Ticket — ist es eine gespeicherte Cross-Site-Scripting-Lücke, die nur darauf wartet, und der Umwandlungsschritt ist die Stelle, an der sie entsteht. Die mitzunehmende Regel ist schlicht: vertrauenswürdiges Markdown zu rendern ist sicher; nicht vertrauenswürdiges Markdown zu rendern verlangt, das entstandene HTML anschließend gegen eine Positivliste von Tags zu bereinigen. Verlassen Sie sich nie darauf, dass der Markdown-Parser Nutzereingaben sicher macht — dafür wurde er nicht gebaut.

Was Markdown bewusst nicht kann

Markdown ist eine Auszeichnungssprache für Prosa, keine Layoutsprache, und seine Grenzen sind Absicht, keine fehlenden Funktionen. Es gibt keine Syntax, um einem Element eine Klasse oder eine ID zu geben, keine Möglichkeit, eine Bildbreite zu setzen, kein Attribut irgendeiner Art. Die Tabellenausrichtung ist die einzige Ausnahme, und selbst sie beschränkt sich auf links, rechts und zentriert. Braucht man das, lautet die Antwort innerhalb von Markdown, HTML inline zu schreiben — das funktioniert und verlässt sofort die portable Teilmenge, denn dieses Fragment erscheint nicht dort, wo HTML entfernt wird. Das ist der Handel im Kern des Formats: Es bleibt als Klartext lesbar, gerade weil es sich weigert zu wachsen. Wenn Sie mehr HTML als Markdown schreiben, ist das Dokument dem Format entwachsen.

Wohin die Ausgabe geht, ändert, was Sie behalten sollten

Das erzeugte HTML ist bewusst nackt — Überschriften, Absätze, Listen und Links, ohne umschließende divs und ohne Klassen — denn genau das erbt ein Stylesheet sauber. Für eine Seite, die Sie kontrollieren, ist das richtig. E-Mail ist die einzuplanende Ausnahme: Die meisten Programme entfernen `<style>`-Blöcke und ignorieren externe Stylesheets, sodass alles, was im Posteingang gestaltet aussehen soll, nach der Umwandlung CSS je Element inline braucht. Das CMS ist der zweite Fall: Viele Editoren bereinigen eingefügtes HTML und werfen Attribute still weg — fügen Sie in der Quelltextansicht ein, nicht in der visuellen. Und wenn das Ziel Markdown direkt annimmt — wie die meisten Static-Site-Generatoren, Wikis und Dokumentationsplattformen —, ist das Umwandeln ein Rückschritt, denn Sie verlieren die leichter zu bearbeitende Quelle.

Warum lokales Umwandeln bei dieser Art Text zählt

Überlegen Sie, was üblicherweise in einem Markdown-Editor steht. Interne Dokumentation, die beschreibt, wie ein System funktioniert. Eine README für ein Repository, das noch nicht öffentlich ist. Ein Blogbeitrag vor der Veröffentlichung. Besprechungsnotizen mit Namen darin. Ein Betriebshandbuch, das Hosts nennt und beschreibt, was bei einem Ausfall zu tun ist. Markdown ist das Format, in dem internes Wissen geschrieben wird, was ein eingefügtes Dokument zur Beschreibung macht, wie eine Organisation arbeitet — selten geheim im dramatischen Sinn und ebenso selten etwas, das man Fremden geben würde. Ein gehosteter Wandler bekommt das alles. Dieses Werkzeug wandelt auf der Seite um und überträgt nichts, nachprüfbar im Netzwerk-Tab der Entwicklerwerkzeuge.

Häufige Fehler, die Sie vermeiden sollten

  • Erwarten, dass ein einzelner Zeilenumbruch die Zeile bricht. Markdown fügt aufeinanderfolgende Zeilen absichtlich zu einem Absatz — nutzen Sie eine Leerzeile für einen neuen Absatz oder einen Backslash am Zeilenende.
  • Von Nutzern eingereichtes Markdown ohne Bereinigung der Ausgabe rendern. Rohes HTML geht laut Spezifikation durch, sodass ein `<script>`-Tag im Kommentar beim Umwandeln zur gespeicherten Skriptlücke wird.
  • Annehmen, jeder Parser spreche denselben Dialekt. Tabellen, Aufgabenlisten und Durchstreichung sind GitHub-Erweiterungen, kein CommonMark — anderswo erscheint eine Tabelle als wörtliche Striche.
  • Zu Inline-HTML greifen, um eine Klasse oder Bildbreite zu setzen. Es funktioniert und verlässt die portable Teilmenge — das Fragment verschwindet überall dort, wo HTML entfernt wird.
  • Markdown umwandeln, das das Ziel direkt angenommen hätte. Static-Site-Generatoren, Wikis und Dokumentationsplattformen nehmen meist Markdown; vorheriges Umwandeln kostet die leichter zu bearbeitende Quelle.

Im Vergleich

KriteriumDieses WerkzeugOnline-WandlerEin Static-Site-Generator
Inhalt an einen Server gesendetNieMeistens jaNein
GitHub-Erweiterungen unterstütztJaUnterschiedlichMeistens
Ausgabe erbt Ihr CSSJaUnterschiedlichJa
Einrichtung nötigKeineKeineInstallieren und einrichten
Konto oder AnmeldungNicht nötigOft verlangtNicht nötig
PreisKostenlosKostenlos / BezahltarifeKostenlos

Funktionen

Tabellen und Aufgabenlisten

Die GitHub-Erweiterungen, die im strikten CommonMark fehlen, in echtem Markdown aber überall vorkommen.

Live-Vorschau

Die gerenderte Ausgabe läuft beim Tippen mit, sodass Fehler sofort auffallen.

Eingezäunte Codeblöcke

Blöcke mit drei Backticks werden zu `pre` und `code`, die Sprache als Klasse vermerkt.

Sauberes, sparsames Markup

Keine umschließenden divs, keine generierten Klassennamen, keine Inline-Stile — das HTML erbt Ihr Stylesheet.

Durchgehend Unicode

Arabischer, türkischer und umlautbehafteter Text geht in beide Richtungen unverändert durch.

Verträgt lange Dokumente

Ganze Handbücher werden ohne Upload und ohne Größenobergrenze umgewandelt.

Nichts zu installieren

Kein Static-Site-Generator, keine Laufzeitumgebung, keine Abhängigkeiten — es läuft auf der Webseite.

Bereit für Arabisch und RTL

Vollständige Oberfläche in acht Sprachen, darunter Arabisch von rechts nach links.

Standardmäßig sicher

Über HTTPS ausgeliefert, ohne Inhaltsverfolgung und ohne Upload an Dritte.

Wer es nutzt

Technische Redaktion

Dokumentation in ein CMS bringen, das HTML annimmt, aber kein Markdown.

Entwicklerinnen und Entwickler

Prüfen, wie eine README aussehen wird, bevor sie in ein Repository geht.

Redaktion und Content

Den Markdown-Entwurf einer Autorin in Markup verwandeln, das das Publikationssystem annimmt.

Newsletter-Redaktion

Den HTML-Rumpf einer E-Mail aus einem in Markdown geschriebenen Entwurf erzeugen.

Häufig Gestellte Fragen

Nein. Alles läuft lokal im Browser — Ihr Text wird nie hochgeladen, gespeichert oder geteilt.

Ja — komplett kostenlos, ohne Konto und ohne Limits.