Kostenloser Markdown Previewer Online

Markdown-Spickzettel

Über Markdown

Markdown wurde von John Gruber, dem Autor hinter dem Daring Fireball-Weblog, mit substanziellem Design-Feedback von Aaron Swartz erstellt. Die erste öffentliche Veröffentlichung, Version 1.0, wurde am 9. März 2004 auf Grubers Site angekündigt; Version 1.0.1, die kanonische Referenz-Veröffentlichung, folgte am 17. Dezember 2004 und ist immer noch die von daringfireball.net/projects/markdown verlinkte Version. Markdown ist gleichzeitig zwei Dinge: eine Klartext-Formatierungssyntax und das ursprüngliche Perl-Skript, das diese Syntax in HTML konvertiert. Grubers erklärtes Ziel war, dass der Quelltext so wie er ist lesbar sein sollte, ein Markdown-Dokument, das in einem Klartext-Editor geöffnet wird, sollte wie eine sorgfältig formatierte E-Mail aussehen, nicht wie ein Tag-Salat. Diese Lesbarkeitsanforderung ist die philosophische Linie, die Markdown von XML-basierten Formaten und schwererem Markup wie LaTeX trennt, und sie ist der Grund, warum jede spätere Erweiterung sich daran messen lassen musste, wie sehr sie die Quelle stört.

Gruber würdigt Swartz ausführlich in den Markdown-Danksagungen: „Aaron Swartz verdient enorme Anerkennung für sein Feedback zum Design der Markdown-Formatierungssyntax.“ Swartz hatte zuvor ein verwandtes leichtgewichtiges Markup namens atx (2002) geschrieben, das den heute vertrauten Überschriftenstil mit # und ## beigesteuert hat, manchmal noch „atx-style headings“ in Parser-Specs genannt. Swartz' Beteiligung ist Teil seines breiteren Vermächtnisses: er hat RSS 1.0 als Teenager mitgebaut, war bis 2007 Mit-Eigentümer von Reddit und beeinflusste offene Web-Standards weiter bis zu seinem Tod 2013. Eine Kuriosität, die man richtig haben sollte: die Dateiendung .md ist heute nahezu universell, aber Grubers Originalwerkzeug verwendete .text: die Migration zu .md war eine Community-Konvention, die sich durchsetzte, sobald Markdown die Blogging-Nische verließ.

Warum Markdown das Web gewonnen hat

Eine Markup-Sprache gewinnt, indem sie von den Plattformen übernommen wird, die den größten Teil des weltweiten Texts veröffentlichen. In einem engen Fünfjahresfenster wurde Markdown von den Plattformen übernommen, die Long-Form-Diskussionen, Code-Zusammenarbeit und Entwickler-Dokumentation beherrschten. Stack Overflow startete am 15. September 2008 mit Markdown als Formatierungssyntax für Fragen, Antworten und Kommentare und verwendete einen Editor namens WMD (Wysiwym Markdown) von John Fraser von AttackLab; das Stack-Overflow-Team schrieb ihn später als Open-Source-Editor PageDown neu, der unter github.com/StackExchange/pagedown gepflegt wird. Reddit, gegründet von Steve Huffman und Alexis Ohanian 2005 mit Aaron Swartz, der kurz danach hinzukam, lieferte Markdown für Kommentare nicht lange nach dem Start aus und trug die Syntax zu einem viel breiteren, nicht entwicklerischen Publikum. GitHub startete 2008 und renderte innerhalb eines Jahres Markdown in README.md und Issue-Kommentaren; 2009 begann es, seinen eigenen Dialekt zu dokumentieren und auszuliefern: GitHub Flavored Markdown. Discord, im Mai 2015 gestartet, übernahm eine Markdown-flavored Chat-Syntax für fett, kursiv, durchgestrichen, Inline-Code, Code-Fences und Blockquotes, was die meisten Nicht-Entwickler unter 25 heute als „Sterne um etwas herum setzen“ verstehen. Die Fähigkeit summiert sich: ein Autor, der Markdown einmal lernt, kann Blogposts in Jekyll/Hugo/Eleventy schreiben, Dokumentation in MkDocs/Docusaurus/Read the Docs, Präsentationen in Marp und Reveal.js, Notizen in Obsidian/Bear/Logseq/Notion, Chat in Slack und Discord, und Quelltext-Dokumentation in praktisch jedem modernen Open-Source-Projekt.

CommonMark, die Unterspezifikation beheben

Grubers ursprüngliche Syntaxbeschreibung von 2004 war berühmt-berüchtigt informell, ein Prosa-Dokument mit Beispielen, keine Grammatik. Sie ließ Dutzende Edge Cases unspezifiziert („wie interagiert Hervorhebung mit Unterstrichen mitten in einem Wort?“; „schließt eine Liste innerhalb eines Blockquotes den Blockquote?“; „was zählt als enge vs lose Liste?“), und Gruber veröffentlichte nie einen Referenz-Parser außer seinem Perl-Skript, dessen Verhalten in Weisen idiosynkratisch war, die andere Implementierer entweder kopieren oder überschreiben mussten. Das Ergebnis Anfang der 2010er-Jahre war, dass GitHub, Reddit, Stack Overflow, Pandoc und der Discount-C-Parser dieselbe Markdown-Quelle alle leicht unterschiedlich renderten, und derselbe Input über Plattformen hinweg brechen konnte.

2012 begannen Stack-Overflow-Mitgründer Jeff Atwood (der damals Discourse leitete) und Pandoc-Autor John MacFarlane eine Anstrengung, eine echte, testbare Spezifikation zu schreiben. Sie wurden begleitet von David Greenspan (Meteor), Vicent Marti (GitHub), Neil Williams (Reddit) und Benjamin Dumke-von der Ehe (Stack Exchange). Das Projekt startete im September 2014 öffentlich als „Standard Markdown“; binnen Tagen widersprach Gruber dem Namen in privater E-Mail, Atwood schrieb einen öffentlichen Beitrag, der die Änderung erklärte, und das Projekt wurde zu „CommonMark“ umbenannt. Die erste nummerierte Veröffentlichung kam am 25. Oktober 2014. Die aktuell veröffentlichte Version ist CommonMark 0.31.2, veröffentlicht am 28. Januar 2024, eine „1.0“ war für 2019 versprochen und ist nicht erschienen, weil eine kleine Anzahl pathologischer Edge Cases (insbesondere rund um Emphasis-Parsing und HTML-Embedding) keine einstimmigen Lösungen produziert haben. In der Praxis wird 0.31.2 als produktionsstabil behandelt. Die CommonMark-Spec ist insofern ungewöhnlich, als 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, fünf Erweiterungen obendrauf

Die formale GFM-Spezifikation, 2017 veröffentlicht und zuletzt am 6. April 2019 als 0.29-gfm versioniert, definiert fünf Erweiterungen oben auf CommonMark: Tabellen (durch Pipe getrennte Blöcke mit einer Trennzeile, die Bindestriche und : für Spalten-weise Ausrichtung verwendet); Aufgaben-Listenelemente (Listeneinträge, die mit [ ] für nicht abgehakt oder [x] für abgehakt beginnen, gerendert als deaktivierte HTML-Checkboxen, GitHub erlaubt zusätzlich angemeldeten Benutzern, diese durch Klicken umzuschalten, was eine UX-Schicht oben auf der Spec ist, nicht Teil der Spec selbst); durchgestrichen (Text in ~~ einzuwickeln erzeugt <del>: CommonMark selbst spezifiziert das nicht); Autolinks-Erweiterung (nackte URLs und E-Mail-Adressen im laufenden Text werden auto-verlinkt, wo CommonMark dies nur für explizite Spitzklammer-Autolinks macht); und verbotenes rohes HTML (eine Sicherheitsbeschränkung, die <script>, <iframe>, <style>, <title>, <plaintext>, <textarea>, <xmp>, <noembed>, <noframes> und eine Handvoll anderer gefährlicher Tags entfernt). Ein sechstes Feature, das gemeinhin GFM zugeschrieben wird, aber vorsichtig zu behandeln ist, sind fenced Code-Blöcke mit Sprach-Identifiern: fenced Code-Blöcke sind Teil von CommonMark selbst; der Sprachhinweis nach dem öffnenden Fence ist ebenfalls CommonMark; das Syntax-Highlighting, das GitHub dann basierend auf diesem Hinweis anwendet, ist GitHubs Render-Verhalten, nicht die Spec. GitHubs Renderer führt auch zusätzliche Nachverarbeitung aus, HTML-Sanitization über sein hauseigenes html-pipeline-Gem, Emoji-Shortcode-Expansion (:smile:), @user- und #issue-Autolinking, nichts davon ist in GFM selbst enthalten.

Die wichtigsten Parser

marked.js wurde von Christopher Jeffrey erstellt, mit dem ursprünglichen Copyright von 2011, und wird seit 2018 von der GitHub-Organisation markedjs gepflegt. Es ist ein Single-Pass-Lexer-dann-Parser-Design, das rohe Geschwindigkeit priorisiert; die Docs positionieren es explizit als „low-level compiler for parsing markdown without caching or blocking“. Es ist der Parser, den dieser Previewer derzeit für das Live-Rendering verwendet. Marked ist klein, schnell, durch Token-Hooks erweiterbar und eines der meist-gestarrten Markdown-Projekte auf GitHub (~36k Sterne).

markdown-it wurde 2014 von Vitaly Puzrin und Alex Kocharin gestartet. Die beiden hatten zuvor fast den gesamten Code zu einem Parser namens Remarkable beigetragen; als Führungsstreitigkeiten den Fortschritt blockierten, organisierten sie dieselbe Autorenschaft um markdown-it neu. Das Projekt wirbt mit 100% CommonMark-Konformität mit optionalen GFM-Schaltern für Tabellen und Durchstreichung sowie einem aggressiven Plugin-Ökosystem (markdown-it-footnote, markdown-it-emoji, markdown-it-attrs, markdown-it-anchor, markdown-it-task-lists und mehrere hundert weitere). Es ist der Parser, der von der eingebauten Markdown-Vorschau von VS Code, der Web-UI von GitLab und einer langen Liste von Static-Site-Generatoren einschließlich Eleventy verwendet wird.

remark / unified.js ist kein einzelner Parser, sondern ein Framework zur Baum-Transformation. Das Unified-Kollektiv, um 2014 gestartet, definiert eine abstrakte Syntaxbaum-Spezifikation namens mdast (Markdown Abstract Syntax Tree); remark parst Markdown in mdast, Plugins manipulieren den Baum, und remark-rehype konvertiert mdast zu hast (dem HTML-AST) zur Emission. Das Modell ist langsamer als marked, aber weitaus komponierbarer. Bemerkenswerte Nutzer sind Prettier (das Markdown mit remark formatiert), Gatsby, MDN, die Node.js-Dokumentations-Pipeline und der inklusiv-Sprachen-Linter alex. Das Unified-Kollektiv listet 312 Projekte und etwa 6,3 Milliarden monatliche npm-Downloads über alle seine Pakete.

MDX, erstmals Ende 2017 von John Otander und anderen mit der Design-Tools-Firma Compositor verbundenen Personen committed, wurde auf dem ZEIT Day 2018 öffentlich angekündigt und lieferte 1.0 am 11. April 2019 aus. MDX kombiniert Markdown-Inhalt mit JSX-Komponenten, sodass ein Autor ein <Chart /> oder ein <Tweet id="123" /> direkt in Prosa einbauen kann. Es treibt die Next.js-Docs, Docusaurus und die meisten React-basierten Dokumentations-Sites an. MDX hat seinen eigenen, von CommonMark unterschiedlichen Parser; v1 basierte auf remark, v2+ verwendet eine spezielle MDX-Grammatik, um JSX-Ausdrücke korrekt im Absatz-Kontext zu handhaben.

Pandoc, der universelle Konverter

Pandoc wurde von John MacFarlane, damals Philosophieprofessor an der University of California, Berkeley, am 10. August 2006 veröffentlicht. Es ist in Haskell geschrieben, und sein Design konzentriert sich auf das Parsen einer von etwa 30 Eingabeformaten (Markdown, reStructuredText, HTML, LaTeX, DocBook, Textile, MediaWiki- und DokuWiki-Markup, Org-Mode, Microsoft Word .docx, OpenDocument, EPUB, JATS XML, Jupyter .ipynb und andere) in ein gemeinsames abstraktes Dokumentmodell und das anschließende Rendern dieses Modells in etwa 40 Ausgabeformate (HTML, PDF über LaTeX oder wkhtmltopdf, .docx, .odt, ePub2/3, Slide-Formate einschließlich Beamer und reveal.js, und vieles mehr). Es ist im akademischen und technischen Verlagswesen allgegenwärtig, weil es Zitate über CSL JSON / BibTeX trägt und sie in formatierte Referenzen für jeden der wichtigsten Zitierstile auflöst. Der Markdown-Dialekt, den Pandoc standardmäßig parst („Pandoc Markdown“), ist selbst eine CommonMark-Obermenge mit Erweiterungen für Fußnoten, Definitionslisten, fenced Divs, Mathematik (LaTeX-Stil $...$ und $$...$$) und Tabellen-Beschriftungen. Pandoc ist GPL v2-or-later lizenziert und ist das, was die meisten akademischen Abteilungen verwenden, um Markdown-Manuskripte in veröffentlichungsbereite Word-Dokumente zu kompilieren.

MultiMarkdown, Markdown Extra und SmartyPants

Zwei frühere Erweiterungsdialekte sind älter als CommonMark und beeinflussten sowohl GFM als auch Pandoc. MultiMarkdown wurde von Fletcher T. Penney mit einer ersten Veröffentlichung im Mai 2007 erstellt (Projektarbeit begann 2005-2006), motiviert durch akademisches Schreiben, Penney wollte ein Markdown, das ein veröffentlichungsfähiges Manuskript mit Fußnoten, Zitaten, Mathematik, Definitionslisten und YAML-artigen Dokument-Metadaten produzieren kann. MultiMarkdown führte Pipe-Zeichen-Tabellen, [^id]-Fußnoten-Marker, Mathematik-Notation, Dokument-Level-Metadatenblöcke am Anfang von Dateien sowie Bild- und Tabellen-Beschriftungen ein oder popularisierte sie. Markdown Extra wurde von Michel Fortin (Autor von PHP Markdown) 2005-2006 erstellt und fügte Pipe-Tabellen, fenced Code-Blöcke mit ~~~ (später auch ```), Fußnoten, Definitionslisten, Abkürzungen und die Attribut-Syntax {#id .class} für Überschriften hinzu. Sein markantester Beitrag war die Lockerung der Markdown-in-HTML-Regeln, das Attribut markdown="1", mit dem Sie Markdown in einem HTML-Block verschachteln können. Mehrere CommonMark- und GFM-Design-Entscheidungen rund um fenced Code und Tabellen gehen auf Markdown Extra zurück. Separat führt SmartyPants: Grubers eigener Typografie-Begleiter von 2002, typografische Substitutionen durch: gerade ASCII-Anführungszeichen werden zu geschwungenen Anführungszeichen, doppelte und dreifache Bindestriche werden zu Halbgeviert- und Geviertstrichen, drei Punkte werden zu einer echten Auslassung. Markdown handhabt die Struktur; SmartyPants handhabt den Schliff; viele Parser bündeln SmartyPants-artiges Verhalten als Nachverarbeitungsschritt (markdown-it-smartypants, remark-smartypants), und Pandoc hat es hinter einem --smart-Flag eingebaut.

Häufige Stolperfallen, zehn Dinge, die neue Autoren beißen

Ein Live-Previewer macht die meisten Parsing-Überraschungen sofort offensichtlich, aber zu verstehen, warum sie passieren, hilft einem Autor, die Quelle beim ersten Mal richtig zu bekommen.

1. Smart-Quote-Konvertierung, die Code-Beispiele bricht. SmartyPants-artige Filter konvertieren fröhlich Anführungszeichen innerhalb dessen, was wie Prosa aussieht (manchmal auch innerhalb von Inline-Code-Spans oder HTML-Attributwerten) und lassen Sie mit kaputtem Markup zurück. Die meisten modernen Parser schließen Code-Spans von der typografischen Substitution aus, aber Blog-Plattformen mit benutzerdefinierten Pipelines tun das oft nicht.
2. Listen-Marker-Erkennung ist Whitespace-empfindlich. -, * und + innerhalb derselben Liste zu mischen, Listen-Fortsetzungsabsätze um weniger einzurücken, als der Marker erfordert, oder eine Leerzeile zwischen Listenelementen zu setzen, kann eine enge Liste in eine lose Liste umkippen lassen (jedes Element in <p>-Tags eingewickelt), ein in der Quelle unsichtbarer, aber in der Ausgabe dramatischer Unterschied.
3. Übereifer beim Autolink. GFM-artiges Autolinking macht jede nackte URL zu einem Link, was in der Regel das ist, was Sie wollen, aber es kann auch URLs verstümmeln, die innerhalb dessen stehen, was ein Code-Span hätte sein sollen, oder URLs mit Klammern (Wikipedia-URLs besonders). Die Regel für „wo endet diese URL?“ variiert zwischen Parsern.
4. Code-Fence-Sprachhinweise. Der Text nach dem öffnenden Triple-Backtick, ```js vs ```javascript vs ```ts vs ```typescript: ist ein Hinweis, keine Spec. Verschiedene Syntax-Highlighter erkennen verschiedene Aliase; Highlight.js, Prism, Shiki und der GitHub-Renderer haben jeweils ihre eigenen Sprachwörterbücher.
5. Tabellen, die Escaping benötigen. Pipe-Zeichen innerhalb von Tabellenzellen müssen als \| escaped werden, sonst werden sie als Spaltentrenner gelesen. Erwischt jeden, der versucht, ein einzeiliges Code-Beispiel in eine Tabellenzelle zu setzen.
6. Harte Zeilenumbrüche. Innerhalb eines Absatzes wird ein einzelner Zeilenumbruch als Whitespace behandelt und die Zeilen werden zusammengefügt; man muss entweder zwei abschließende Leerzeichen am Zeilenende setzen oder einen Backslash verwenden, je nach Parser. CommonMark erlaubt beides. Einige ältere Parser verlangen einen expliziten <br>.
7. Gemischtes Markdown und HTML. Markdown wurde so konzipiert, dass beliebiges HTML durchgereicht wird, also funktioniert es, ein <div class="callout"> in eine Markdown-Datei einzufügen. Aber sobald Sie Markdown-Syntax innerhalb eines HTML-Blocks platzieren, divergieren die Parser: CommonMark behandelt die meisten HTML-Blöcke als undurchsichtig; Markdown Extra führte markdown="1" ein, um in verschachteltes Parsing einzusteigen.
8. HTML-Entities und Zeichen-Escapes. Ein Ampersand & in einer URL braucht innerhalb eines Markdown-Links kein Escaping, aber dasselbe & außerhalb eines Links wird an HTML weitergegeben und muss möglicherweise & sein, um strenger HTML5-Konformität zu genügen. Die meisten Renderer behandeln das automatisch; manche nicht.
9. Überschriften-IDs. GitHub generiert URL-Fragment-IDs aus dem Überschriftentext mit einer Slugify-Regel automatisch; viele Parser tun das auch, aber die Slugify-Algorithmen unterscheiden sich. Gleiche Überschrift, anderer Anker plattformübergreifend, eine ständige Ursache für kaputte Intra-Dokument-Links, wenn Inhalt zwischen Systemen wandert.
10. Abschließendes Whitespace und Editor-Einstellungen. Editoren, die abschließendes Whitespace beim Speichern entfernen, löschen still Markdowns Zwei-Trailing-Spaces-Zeilenumbruch-Syntax. Editoren, die Tabs in Leerzeichen umwandeln (oder umgekehrt), brechen Codeblöcke, die von Einrückung abhängen.

Markdown und Sicherheit, XSS und Sanitization

Markdown ist auf eine bestimmte Weise gefährlich: jeder Mainstream-Parser reicht rohes HTML unverändert durch. Das ist beabsichtigt (es ist das, was Markdown für handgeschriebene Callouts und Embeds nützlich macht) aber es bedeutet auch, dass ein Markdown-Previewer, der Parser-Ausgaben direkt in den DOM einfügt, standardmäßig ein XSS-Vektor ist. <img src=x onerror="alert(1)"> in einen Markdown-Editor einzufügen und die Ausgabe ohne Sanitization zu rendern, wird die Alarmmeldung ausführen. Zwei Verteidigungsschichten sind Standard. Erstens, parser-level Konfiguration: marked.js, markdown-it und remark legen alle Optionen offen, um rohes HTML zu deaktivieren oder bei der Ausgabe zu escapen (markdown-it hat html: false standardmäßig; remark/rehype hat rehype-sanitize). GFM spezifiziert zusätzlich die „verbotenes rohes HTML“-Erweiterung, die eine fest codierte Liste gefährlicher Elemente entfernt. Zweitens und robuster, HTML-Sanitization nach dem Parsen: DOMPurify, von der Berliner Sicherheitsfirma Cure53 ab Februar 2014 geschrieben, ist der De-facto-JavaScript-Sanitizer. Es nimmt einen HTML-String, parst ihn in einen DOM, läuft den Baum entlang und erlaubt nur eine konfigurierbare sichere Teilmenge von Elementen und Attributen, und serialisiert das Ergebnis. DOMPurify entfernt <script>, blockiert Inline-Event-Handler, entfernt javascript:-URLs und behandelt hundert subtile XSS-Bypasses (SVG-<use>-Missbräuche, MathML-Attribut-Polyglots), die ein naiver Regex-Sanitizer übersehen würde. Die empfohlene Pipeline für jeden browserbasierten Previewer, der rohes HTML akzeptiert, lautet: markdownString → Parser → htmlString → DOMPurify.sanitize() → innerHTML. CommonMark verlangt auch explizit, dass Parser javascript:-URIs in Autolinks ablehnen; die meisten Parser dehnen diese Ablehnung auf alle Linkformen aus.

Markdown vs reStructuredText vs AsciiDoc

Markdown ist die dominierende leichtgewichtige Markup-Sprache, aber nicht die einzige. reStructuredText (reST) wurde im Juni 2001 erstmals von David Goodger als Teil der Python Doc-SIG veröffentlicht und entwickelte sich aus einem früheren Zope-Format namens StructuredText. Es wurde 2002 zum offiziellen Dokumentationsformat von Python und ist die Eingabesprache für Sphinx, den Dokumentationsgenerator hinter fast allen Python-Projekt-Docs (die offiziellen Python-Sprachdocs, NumPy, SciPy, Django, Flask, scikit-learn, pandas, die Linux-Kernel-Dokumentation seit 2016, CMake, LLVM). RSTs Designphilosophie ist im Wesentlichen das Gegenteil von Markdowns: es akzeptiert mehr visuelles Rauschen in der Quelle im Austausch für mehr semantische Präzision in der Ausgabe. RST hat einen eingebauten Erweiterungsmechanismus über „Direktiven“ (.. note::, .. code-block:: python) und „Rollen“ (:func:, :ref:), mit dem ein Projekt domänenspezifisches Markup definieren kann, ohne das Format zu verlassen. AsciiDoc wurde 2002 von Stuart Rackham als Python-Werkzeug erstellt, das absichtlich auf DocBook-XML-Semantik abzielt (jedes AsciiDoc-Dokument wird sauber auf DocBook abgebildet) und ist damit das Markup der Wahl für Projekte, die Bücher in Veröffentlichungsqualität, technische Spezifikationen und Handbücher benötigen. AsciiDoc ist das, worin die Dokumentation des Git-Projekts geschrieben ist, was O’Reilly Media für viele seiner Bücher verwendet, was Red Hat und Mozilla für mehrere Produktdokumentations-Sätze verwenden, und was GitHub und GitLab nativ als README.adoc-Alternative unterstützen. Die ursprüngliche Python-Implementierung wurde durch Asciidoctor abgelöst, eine 2013 veröffentlichte Ruby-Implementierung. Praktische Empfehlung: wählen Sie Markdown für Blogposts, READMEs, Chat, Notizen und die meiste Dokumentation; reStructuredText für Python-Dokumentation, die von Sphinx verarbeitet wird; AsciiDoc für lange Bücher oder Spezifikationen, die gleichzeitig zu DocBook, PDF und EPUB mit voller semantischer Treue rendern müssen.

Häufig gestellte Fragen

Welche Markdown-Funktionen werden unterstützt?

Dieser Previewer unterstützt Überschriften, Fett, Kursiv, Links, Bilder, Listen, Blockzitate, Codeblöcke, Tabellen, horizontale Linien und Durchstreichungen. Er deckt die CommonMark-Spezifikation sowie gängige Erweiterungen ab.

Kann ich das gerenderte HTML exportieren?

Sie können die gerenderte Ausgabe aus dem Vorschaufenster kopieren. Für das rohe HTML klicken Sie mit der rechten Maustaste auf die Vorschau und nutzen Sie die "Untersuchen"- oder "Quelltext anzeigen"-Funktion Ihres Browsers, um das generierte Markup zu kopieren.

Wird mein Text gespeichert?

Nein. Alles läuft in Ihrem Browser, nichts wird gespeichert oder an einen Server gesendet. Schließen Sie den Tab und Ihr Text ist weg. Kopieren Sie Ihr Markdown vor dem Verlassen, wenn Sie es speichern möchten.

Wird mein Text gespeichert oder irgendwohin gesendet?

Nein. Der Markdown-Parser läuft vollständig in Ihrem Browser über JavaScript. Nichts wird hochgeladen, keine API wird aufgerufen, keine Logs werden geschrieben. Schließen Sie den Tab und der Text ist weg. Wenn Sie behalten möchten, was Sie geschrieben haben, kopieren Sie es vor dem Verlassen der Seite. Sie können die Seite auch offline verwenden, sobald sie einmal geladen wurde, das Service-Worker-Caching bedeutet, dass der Parser ohne Internetverbindung verfügbar bleibt.

Sanitisiert der Previewer rohes HTML?

Der Parser reicht rohes HTML durch, was das CommonMark-Standardverhalten ist, nützlich für das gelegentliche Einbetten eines <div> oder <details>. Da die Eingabe aus Ihrer eigenen Browser-Sitzung stammt und die Ausgabe nur in Ihrem eigenen Tab gerendert wird, ist dies sicher für den Ein-Personen-Vorschau-Anwendungsfall, für den es gebaut wurde. Wenn Sie die Ausgabe auf einem Mehrbenutzer-System veröffentlichen (ein CMS, ein Forum, eine Dokumentations-Site, die Benutzer-Einreichungen akzeptiert), sollten Sie das gerenderte HTML immer durch einen Sanitizer wie DOMPurify laufen lassen, bevor Sie es in eine öffentliche Seite einfügen, Markdown plus rohes HTML ist ein XSS-Vektor in jedem System, in dem Schreiber und Leser unterschiedliche Personen sind.

Gibt es Größenbeschränkungen für Dateien?

Keine harte Grenze. Der Parser handhabt Zehntausende Zeilen Markdown ohne Probleme auf einem typischen Laptop. Das Live-Re-Rendering läuft bei jedem Tastendruck, also werden sehr große Dokumente (ein ganzes Buch in einer einzigen Datei) auf langsameren Geräten anfangen, sich träge anzufühlen. Die Aufteilung in Kapitel oder das Einfügen von Inhalten zum einmaligen Rendern und anschließenden Offline-Bearbeiten ist die Lösung. Die Seite wird Ihren Browser nicht einfrieren, marked.js ist einer der schnellsten verfügbaren Markdown-Parser.

Verwandte Werkzeuge