Ein Linter für dein Markdown, mit Erklärungen für Menschen
Markdown sieht einfach aus, bis deine README, dein Docs-Site oder dein Blog-Post inkonsistent wirken: gemischte List-Marker (Bullet-Stil), Trailing-Whitespace, Headings, die eine Stufe überspringen (Heading-Level), Fenced-Code-Blöcke ohne Language-Tag. Ein Renderer rendert die Seite trotzdem, aber das Ergebnis ist schlampig und das Diff-Rauschen enorm.
Dieses Tool lässt die gleiche Engine wie die CLI `markdownlint` (markdownlint) auf deinem Text laufen. Du kriegst eine nummerierte Liste der Issues, jedes mit dem Regel-Code (`MD009`, `MD040`, ...), einer One-Line-Beschreibung und, wo auto-fixbar, einer Fix-Vorschau. Klick eine Zeile, das Textfeld scrollt dorthin.
Vier Presets decken die üblichen Wahl-Optionen: Recommended (Default, sinnvoll für jedes Projekt), GitHub (GFM-freundlich), Strict (80-Spalten-Zeilen plus keine doppelten Headings), Custom rules (alles an). Fix mode anschalten, um den bereinigten Text zu sehen und in einem Klick zu kopieren.
So nutzt du das Tool
- Dein Markdown ins große Textfeld links pasten. Ein kleines Sample mit absichtlichen Issues ist per Default geladen, damit das Tool gleich was zeigt.
- Preset oben wählen: Recommended für fast jedes Projekt, GitHub für Files, die auf GitHub oder GitLab gehen, Strict für technische Docs mit jeder Regel plus 80-Spalten-Zeilen, Custom rules für jeden verfügbaren Check.
- "Run lint" klicken. Das rechte Panel füllt sich mit einer nummerierten Liste von Issues. Jedes zeigt den Regel-Code (z. B. `MD040`), eine kurze Beschreibung, das relevante Snippet und ein "auto-fix"-Badge, wenn markdownlint es für dich fixen kann.
- Beliebige Issue-Zeile klicken, um zur Zeile im Textfeld zu springen. Die Zeile ist selektiert, also kannst du direkt editieren. Praktisch, um Dutzende Issues zu triagieren, ohne manuell zu scrollen.
- "Fix mode" umschalten, um den bereinigten Output statt deines Rohinputs zu sehen. Alle auto-fixbaren Issues werden angewandt. Die strukturellen (Heading-Stil, Language-Tags, Content-Fehler) fixt du von Hand.
- "Copy" drücken, um entweder deinen Rohinput oder den bereinigten Output zu kopieren (je nach Fix-Modus). Das ist der String, den du zurück in deine README oder Doku pastest.
- FAQ unten lesen, wenn du wissen willst, was eine bestimmte Regel bedeutet oder welches Preset zur Team-Konvention passt. Jeder Regel-Code verlinkt auf eine kurze Plain-Language-Erklärung.
Wann das nützlich ist
Sechs konkrete Situationen, in denen ein Markdown-Linter echt Zeit spart:
- README vorm Pushen prüfen. Du hast 300 Zeilen geschrieben, hast in der ersten Hälfte `-` für Bullets genutzt und in der zweiten `*`, drei deiner Code-Blöcke fehlen Language-Tags, also rendert der Syntax-Highlighter auf GitHub sie monochrom. Linten, fixen, pushen.
- Docs-Site (Astro, Hugo, Docusaurus, MkDocs) onboarden. Der Generator wrappt jede Seite in ein Layout. Schlechtes Markdown taucht als schiefe Tabellen, kaputte Anker-Links und inkonsistente Heading-Hierarchie in der Sidebar auf. Linten vorm Hinzufügen der Seiten fängt das alles.
- Code-Review eines Kollegen-PR. Sie haben Markdown aus Notion gepastet, was gerne Trailing-Whitespace und Smart-Quotes emittet. Linten, Liste in den PR-Kommentar pasten, "hier sind 12 Sachen zum Fixen".
- Tutorial vorm Publishen auf Medium oder dev.to säubern. Beide Plattformen haben eigene Markdown-Quirks. Strict-Preset lokal vorab laufen lassen eliminiert das was-rendert-wo-Raten.
- Von einer anderen Plattform migrieren. Du hast Posts aus WordPress, Ghost oder Substack als Markdown exportiert. Sie sind voller Inline-HTML-`<div>`-Wrapper, rohe URLs, die auto-verlinkt sein sollten, und Headings, die bei H2 starten. Der Linter sieht das alles.
- Einen Pre-Commit-Hook in CI einrichten. Dieselben Regeln wie hier wandern in eine Config-Datei in deinem Repo, du kriegst einen grünen Check in CI-Runs und einen freundlichen Kommentar auf jedem PR, der sie bricht.