Plak twee Markdown-documenten en zie regel voor regel wat is veranderd. Werkt op README-bestanden, release notes, MDX en documenten met frontmatter. De diff draait in je browser.
Een gratis tool die volledig in de browser draait om twee Markdown-documenten op het niveau van de brontekst te vergelijken. Plak een oude README.md links, de bijgewerkte versie rechts, en elke gewijzigde kop, lijst-item, link, codeblok en tabelcel licht op. Niets verlaat je apparaat.
De diff werkt teken voor teken. Markdown is platte tekst, dus dit is de juiste primitief: je ziet de letterlijke wijziging in de bron van het document, geen gok over hoe een renderer het zou interpreteren.
Als je onze tekst-diff al gebruikt voor algemene proza, is de Markdown-pagina dezelfde engine met teksten gericht op de gevallen die opduiken wanneer je echt documentatie schrijft. Voor het vergelijken van YAML-frontmatter-blokken bovenaan Jekyll-, Hugo- of MkDocs-bestanden gaat de YAML-pagina beter om met de op inspringing gevoelige structuur. Strikte gestructureerde data met sleutel/waarde-lookups hoort thuis in de JSON-diff.
De diff is op tekenniveau. Na de ruwe diff schuift een semantische opschoonpassage de markeringen zo dat ze op hele woorden, lijstitems en linkdoelen vallen, in plaats van een inline `code span` doormidden te knippen of de leidende ## van een kop af te breken. Toevoegingen kleuren rechts groen, verwijderingen links rood.
Het is een diff op de brontekst, niet op de gerenderde uitvoer. Dat is de juiste primitief voor Markdown-werk en het telt zwaarder dan het klinkt. Twee documenten die naar identieke HTML renderen kunnen heel verschillende bronnen hebben: **vet** tegenover __vet__, opsommingen met * tegenover -, vier spaties inspringing tegenover een tab in een geneste lijst. Een renderer plet dat allemaal naar dezelfde uitvoer en je verliest het signaal. Wanneer je wilt weten of een bijdrager echt alleen een typefout heeft hersteld, beantwoordt de bron-diff die vraag.
Markdown is daarnaast een familie van dialecten. De originele specificatie van John Gruber (zie daringfireball.net) was bewust losjes, en in de loop van de tijd trokken CommonMark, GitHub Flavored Markdown, Pandoc en MultiMarkdown elk een andere kant op. Tabellen bestaan in GFM en Pandoc maar niet in CommonMark. Doorhalen met ~~ en takenlijsten met - [ ] zijn GFM-uitbreidingen. De diff-tool maakt het dialect niet uit; hij toont de ruwe tekst. De smaak telt wanneer je je begint af te vragen of een alinea nog goed rendert onder het nieuwe docs-thema, en dat is een vraag voor je renderer, niet voor de diff.
Twee tekstvensters, één diff. Geen registratie, geen upload, geen serverronde.
Plak de oude versie links, de nieuwe rechts. Of klik in een van de panelen op Uploaden om een .md-, .markdown- of .mdx-bestand te laden. De Voorbeeld-knop vult beide kanten met een klein README, zodat je de diff in actie ziet voor je je eigen content plakt.
Een bestand bewerkt op Windows heeft meestal CRLF-regeleinden; een bestand van een Linux-server LF. Een teken-diff behandelt dat als verschillend, waardoor elke regel als gewijzigd kan worden gekleurd. Als de diff er verdacht vol met rood en groen uitziet, normaliseer dan eerst beide bestanden naar hetzelfde regeleinde in je editor. VS Code toont het actieve regeleinde in de statusbalk onderaan.
Verwijderingen verschijnen links in rood, toevoegingen rechts in groen. De twee panelen scrollen synchroon. Frontmatter-blokken, code-fences, tabelrijen en lijst-items zijn voor de diff-engine allemaal slechts tekst, dus wijzigingen daarbinnen komen op dezelfde manier naar voren als wijzigingen in de hoofdtekst. De wijzigingstellers in elke kop geven een snelle indicatie van hoe zwaar er is bewerkt.
Je wilt snel zien wat er is veranderd in README.md op een PR-branch ten opzichte van main, maar je wilt niet GitHub openen, langs de gerenderde preview scrollen en drie menu's diep op "Display the source diff" klikken. Plak in plaats daarvan de twee ruwe bestanden in deze tool. Koppen, code-fences en linkdoelen komen helder naar voren. Handig wanneer de PR ook honderd bronbestanden raakt en de docs-wijziging in de ruis verdwijnt.
Release notes gaan voor publicatie door meerdere bewerkingen. Concepten worden herschikt, opsommingen samengevoegd, versienummers verschuiven. Een diff van de eerder gepubliceerde RELEASE_NOTES.md tegen het nieuwe concept vangt verloren regels en per ongeluk gemaakte duplicaten op, iets waar de gerenderde preview slecht in is omdat het oog over op elkaar lijkende regels glijdt. De diff maakt het ook makkelijk om te controleren of de sectie ## Breaking changes echt is gegroeid tussen releases.
Je team schrijft docs in Markdown in een Git-repo, maar de openbare site wordt gegenereerd door een CMS of statische sitegenerator zoals MkDocs, Hugo of Docusaurus. Soms loopt de gepubliceerde pagina uiteen met de bron: iemand heeft de live pagina via de CMS-UI bewerkt en is vergeten terug te pushen, of een CI-stap heeft het bestand herschreven. Exporteer de gepubliceerde pagina als Markdown, leg hem in één paneel, leg de .md uit de repo in het andere, en de afwijking ligt in seconden voor je.
Je hebt een blogpost in Markdown naar een redacteur gestuurd. De redacteur stuurde een gemarkeerde versie terug. Een diff tussen de twee verwerkt de feedback veel sneller dan alinea voor alinea opnieuw lezen, vooral wanneer de redacteur secties heeft verschoven of je inleiding heeft herschreven. Werkt net zo goed voor ghostgeschreven content waarbij de schrijver wil bevestigen welke stem-aanpassingen het redactiewerk hebben overleefd.
Een Docusaurus- of Astro-site migreren van .md naar .mdx klinkt onschuldig, totdat je merkt dat sommige imports zijn verschoven, dat JSX-componenten Markdown-tabellen hebben vervangen en dat een paar code-fences nu in eigen componenten zijn verpakt. Diff de oude page.md tegen de nieuwe page.mdx bestand voor bestand en de migratiekeuzes worden controleerbaar. Hetzelfde proces andersom als je besluit dat MDX een vergissing was en wilt terugkeren naar gewoon Markdown.
Een korte lijst met de syntax-randgevallen die deze tool het vaakst aan het licht brengt. De dialect-kolom vertelt welke smaken de functie echt ondersteunen, want daar komen de meeste verrassingen tussen renderers vandaan.
| Topic | What this tool does |
|---|---|
| Drift tussen smaken | Markdown is een familie. CommonMark is de feitelijke basis. GFM voegt tabellen, takenlijsten, doorhalen en autolinks toe. Pandoc en MultiMarkdown voegen voetnoten, definitielijsten en meer toe. Dezelfde bron kan tussen die smaken erg verschillend renderen. |
| Tabellen | Tabellen met pijpjes bestaan in GFM en Pandoc. Ze zijn geen onderdeel van CommonMark of het oorspronkelijke Markdown. Als een renderer ruwe |-tekens print in plaats van cellen, is de parser CommonMark-strikt en heb je een GFM-compatibele nodig. |
| Doorhalen | ~~tekst~~ is een GFM-uitbreiding. Origineel Markdown en CommonMark ondersteunen het niet. Pandoc ondersteunt het met de uitbreiding strikeout aan. Als je tekst rendert met letterlijke tildes, is de renderer niet GFM-bewust. |
| Takenlijsten | - [ ] todo en - [x] klaar zijn een GFM-uitbreiding. CommonMark rendert ze als gewone opsommingen met letterlijke haken. GitHub, GitLab en de meeste moderne docs-sites ondersteunen ze; gewone Markdown-processors meestal niet. |
| Codeblokken: gefenced vs ingesprongen | Gefencede codeblokken (drie backticks of tildes, met optionele taaltag) zijn CommonMark en universeel ondersteund. De originele specificatie had alleen codeblokken met vier spaties inspringing, die nog werken maar geen taalhint kunnen dragen. Beide in één bestand mengen is toegestaan, maar rommelig. |
| Harde regelafbrekingen | Drie opties: een regel afsluiten met twee spaties achter de regel, afsluiten met een backslash \ (CommonMark en GFM, niet origineel) of een lege regel invoegen voor een alinea-overgang. Spaties achter de regel zijn in de meeste editors onzichtbaar, daarom overleven harde afbrekingen vaak een diff die geen mens opmerkt. |
| Frontmatter | YAML tussen ----fences, TOML tussen +++ of JSON tussen { } bovenaan het bestand. Geen onderdeel van de Markdown-specificatie, maar alomtegenwoordig in Jekyll, Hugo, MkDocs, Docusaurus en Astro. Renderers verwijderen het voor ze de body parseren. |
| Inline-HTML | CommonMark staat ruwe HTML-tags binnen Markdown toe. GFM ook, maar past bij rendering op github.com een HTML-sanitizer toe. Sommige statische sitegeneratoren saneren, andere laten HTML door en een paar escapen het. Diffs van pagina's met ingebedde <div>- of <iframe>-blokken zien we vaak bij migratie-audits. |
Nee. De tool maakt een diff van de Markdown-brontekst, niet van de HTML die een renderer zou produceren. Dat is opzet. Twee documenten kunnen naar identieke HTML renderen en toch betekenisvol verschillende bronnen hebben, bijvoorbeeld opsommingen geschreven met * tegenover - of vet geschreven met ** tegenover __. Een diff op bronniveau bewaart dat signaal. Wil je zien hoe het document rendert, plak het dan in je gebruikelijke previewer: de GitHub-web-UI, VS Code of je statische sitegenerator.
Een diff van gerenderde HTML vertelt je wat lezers gaan zien. Een bron-diff vertelt je wat er werkelijk in het bestand is veranderd. Ze beantwoorden verschillende vragen. Voor Markdown is de bron-diff bijna altijd de nuttigste, omdat hij de bewerkingen van de auteur trouw laat zien: een kopniveau dat van ## naar ### is gegaan, een gefenced codeblok dat van taaltag is gewisseld, een relatieve link die absoluut is geworden. Wil je een vergelijking op HTML-niveau, haal beide bestanden dan eerst door je renderer en diff de uitvoer.
De diff zelf parseert geen Markdown, dus het maakt hem niet uit welk dialect je gebruikt. Tabellen, takenlijsten, doorhalen en autolinks zien er gewoon uit als tekst. De smaak telt wanneer je je afvraagt of je document nog goed rendert. CommonMark komt het dichtst bij een basisspecificatie, en GitHub Flavored Markdown is CommonMark plus tabellen, takenlijsten, doorhalen en autolinks. Kies wat je doelrenderer ondersteunt.
Frontmatter is gewoon tekst bovenaan het bestand, omsloten door --- voor YAML of +++ voor TOML. Statische sitegeneratoren als Hugo, Jekyll en MkDocs gebruiken het voor pagina-metadata. De diff behandelt het blok als gewone tekst, dus wijzigingen aan title:, date: of tags: verschijnen als elke andere regel. Als je frontmatter groot en gevoelig voor inspringing is, is onze YAML-diff-pagina beter geschikt voor dat blok afzonderlijk.
Ja. MDX is Markdown met ingebedde JSX-componenten, en de JSX is vanuit het oogpunt van de diff gewoon meer tekst. Je kunt een .mdx-bestand in een van de panelen plakken en de diff brengt wijzigingen in imports, component-props en de omringende Markdown op dezelfde manier naar boven als bij .md. Het enige dat de tool niet doet, is valideren of je JSX compileert; dat is de taak van de MDX-compiler. Voor pure code-review van de JSX-stukken plak je ze in onze tekst-diff.
Regeleinden zijn tekens, dus een bestand opgeslagen met Windows-CRLF en een bestand opgeslagen met Unix-LF differen op elke regel. Als je panelen er vol met spookwijzigingen uitzien, is dit bijna altijd de oorzaak. De oplossing is beide bestanden voor het plakken in je editor naar hetzelfde regeleinde te normaliseren; in VS Code wordt het actieve regeleinde in de statusbalk onderaan getoond en wissel je dat met één klik. Ook Gits instelling core.autocrlf kan tussen machines verrassende CRLF-verschillen introduceren.
Je Markdown verlaat nooit je browser. De editor, de diff en de formatter draaien allemaal op je apparaat. Geen analytics op je invoer, geen logs, geen serverronde. Achtergrondinformatie over het formaat zelf staat op Wikipedia, met de meest recente CommonMark-specificatie op spec.commonmark.org/0.31.2 en de GitHub-smaak op github.github.com/gfm.