Klistra in två Markdown-dokument och se rad för rad vad som ändrats. Funkar på README-filer, release notes, MDX och dokument med frontmatter. Diffen körs i din webbläsare.
Ett gratis verktyg som körs helt i webbläsaren för att jämföra två Markdown-dokument på källtextnivå. Klistra in en gammal README.md till vänster, den uppdaterade till höger, så lyser varje ändrad rubrik, listpunkt, länk, kodblock och tabellcell upp. Inget lämnar din maskin.
Diffen jobbar tecken för tecken. Markdown är vanlig text, så det är rätt primitiv: du ser den faktiska ändringen i dokumentkällan, inte en gissning om hur en renderare skulle tolka den.
Använder du redan vår text-diff för allmän prosa är Markdown-sidan samma motor med text inriktad på de fall som dyker upp när man faktiskt skriver dokumentation. För att jämföra YAML-frontmatter-block överst i Jekyll-, Hugo- eller MkDocs-filer hanterar YAML-sidan den indragsberoende strukturen bättre. Sträng strukturerad data med nyckel/värde-uppslag hör hemma i JSON-diffen.
Diffen är på teckennivå. Efter den råa diffen flyttar en semantisk städpassage markeringarna så att de hamnar på hela ord, listpunkter och länkmål istället för att klippa en inline `code span` mitt itu eller riva av det inledande ## från en rubrik. Tillägg målas gröna till höger, borttagningar röda till vänster.
Det är en diff på källtexten, inte på den renderade utdatan. Det är rätt primitiv för Markdown-arbete och det väger tyngre än det låter. Två dokument som renderar till identisk HTML kan ha väldigt olika källor: **fet** mot __fet__, listpunkter med * mot -, fyra mellanslag mot ett tabbtecken i en nästlad lista. En renderare plattar ihop allt det till samma utdata och du tappar signalen. När du vill veta om en bidragsgivare verkligen bara fixade ett stavfel är det källdiffen som svarar.
Markdown är dessutom en familj av dialekter. Den ursprungliga specifikationen av John Gruber (se daringfireball.net) var medvetet lös, och med tiden drog CommonMark, GitHub Flavored Markdown, Pandoc och MultiMarkdown åt var sitt håll. Tabeller finns i GFM och Pandoc men inte i CommonMark. Genomstrykning med ~~ och uppgiftslistor med - [ ] är GFM-tillägg. Diff-verktyget bryr sig inte om dialekt; det visar råtexten. Smaken spelar roll när du börjar fråga om ett stycke fortfarande renderar rätt under det nya doc-temat, vilket är en fråga för din renderare, inte för diffen.
Två textrutor, en diff. Ingen registrering, ingen uppladdning, ingen serverresa.
Klistra in den gamla versionen till vänster, den nya till höger. Eller klicka på Ladda upp i någon av rutorna för att läsa in en .md-, .markdown- eller .mdx-fil. Knappen Exempel fyller båda sidorna med en liten README så du ser diffen jobba innan du klistrar in eget innehåll.
En fil som redigerats på Windows har oftast CRLF-radslut; en fil från en Linux-server har LF. En teckendiff behandlar dessa som olika, vilket kan måla varje rad som ändrad. Om diffen ser misstänkt full av rött och grönt ut, normalisera först båda filerna till samma radslut i din editor. VS Code visar aktivt radslut i statusraden längst ner.
Borttagningar visas röda till vänster, tillägg gröna till höger. De två rutorna scrollar synkront. Frontmatter-block, kodstaket, tabellrader och listpunkter är alla bara text för diffmotorn, så ändringar i dem dyker upp likadant som ändringar i brödtexten. Ändringsräknarna i varje rubrik ger en snabb mätare på hur tung redigeringen var.
Du vill snabbt se vad som ändrats i README.md i en PR-gren mot main, men du vill inte öppna GitHub, scrolla förbi den renderade förhandsvisningen och klicka "Display the source diff" tre menyer ner. Klistra istället in de två råa filerna i det här verktyget. Rubriker, kodstaket och länkmål kommer fram tydligt. Användbart när PR:en också nuddar hundra källfiler och dokumentationsändringen försvinner i bruset.
Release notes går igenom flera redigeringar innan de släpps. Utkast omfördelas, punkter slås ihop, versionsnummer flyttar sig. En diff av tidigare publicerade RELEASE_NOTES.md mot det nya utkastet fångar tappade poster och oavsiktliga dubbletter, något som den renderade förhandsvisningen är dålig på eftersom ögat glider över rader som ser likadana ut. Diffen gör det också lätt att verifiera att avsnittet ## Breaking changes verkligen växt mellan releaser.
Ditt team skriver dokumentation i Markdown i ett Git-repo, men den publika sidan genereras av ett CMS eller en statisk sajtgenerator som MkDocs, Hugo eller Docusaurus. Ibland glider den publicerade sidan från källan: någon redigerade den live via CMS-gränssnittet och glömde pusha tillbaka, eller ett CI-steg skrev om filen. Exportera den publicerade sidan som Markdown, släpp in den i en ruta, släpp in repots .md i den andra, så ligger glidningen framför dig på sekunder.
Du skickade ett blogginlägg till en redaktör i Markdown. Redaktören skickade tillbaka en markerad version. En diff mellan de två tar upp feedbacken mycket snabbare än att läsa om stycke för stycke, särskilt när redaktören har omfördelat sektioner eller skrivit om din ingress. Funkar lika bra för spökskrivet innehåll där författaren behöver bekräfta vilka tonjusteringar som överlevde redigeringen.
Att migrera en Docusaurus- eller Astro-sajt från .md till .mdx låter som en harmlös operation, tills du upptäcker att en del importer flyttats, JSX-komponenter ersatt det som tidigare var vanliga Markdown-tabeller och några kodstaket nu är inlindade i egna komponenter. Diffa gamla page.md mot nya page.mdx fil för fil, så blir migrationsbesluten granskningsbara. Samma flöde i omvänd riktning om du beslutar att MDX var ett misstag och vill tillbaka till vanlig Markdown.
En kort lathund för de syntaxgränsfall det här verktyget oftast visar. Dialektkolumnen säger vilka smaker som faktiskt stöder funktionen, för det är därifrån de flesta överraskningarna mellan renderare kommer.
| Topic | What this tool does |
|---|---|
| Glidning mellan smaker | Markdown är en familj. CommonMark är de facto-grunden. GFM lägger till tabeller, uppgiftslistor, genomstrykning och autolänkar. Pandoc och MultiMarkdown lägger till fotnoter, definitionslistor och mer. Samma källa kan rendera mycket olika mellan dem. |
| Tabeller | Pipe-avgränsade tabeller finns i GFM och Pandoc. De är inte en del av CommonMark eller original-Markdown. Om en renderare skriver ut råa |-tecken istället för celler är parsern strikt CommonMark och du behöver en GFM-kompatibel. |
| Genomstrykning | ~~text~~ är ett GFM-tillägg. Original-Markdown och CommonMark stöder det inte. Pandoc stöder det med tillägget strikeout aktivt. Om din text renderas med bokstavliga tildetecken känner inte renderaren till GFM. |
| Uppgiftslistor | - [ ] todo och - [x] klart är ett GFM-tillägg. CommonMark renderar dem som vanliga listpunkter med bokstavliga klamrar. GitHub, GitLab och de flesta moderna doc-sajter stöder dem; vanliga Markdown-processorer gör det vanligtvis inte. |
| Kodblock: med staket vs indragna | Kodblock med staket (tre backticks eller tildetecken, med valfri språktagg) är CommonMark och stöds överallt. Originalspecifikationen hade bara kodblock med fyra mellanslags indrag, vilka fortfarande funkar men inte kan bära en språkledtråd. Att blanda båda i en fil är tillåtet men slarvigt. |
| Hårda radbrytningar | Tre alternativ: avsluta en rad med två avslutande mellanslag, avsluta med ett bakåtsnedstreck \ (CommonMark och GFM, inte original) eller infoga en tom rad för styckebrytning. Avslutande mellanslag är osynliga i de flesta editorer, vilket är varför hårda brytningar ofta överlever en diff som ingen människa upptäcker. |
| Frontmatter | YAML mellan ----staket, TOML mellan +++ eller JSON mellan { } allra överst i filen. Inte en del av Markdown-specifikationen alls, men allestädes närvarande i Jekyll, Hugo, MkDocs, Docusaurus och Astro. Renderare tar bort det innan de parsar brödtexten. |
| Inline-HTML | CommonMark tillåter råa HTML-taggar inuti Markdown. GFM gör det också men tillämpar en HTML-saneringsprocess vid rendering på github.com. Vissa statiska sajtgeneratorer sanerar, andra släpper igenom HTML och ett par escapar det. Diffar av sidor med inbäddade <div>- eller <iframe>-block är vanliga vid migrationsgranskningar. |
Nej. Verktyget diffar Markdownens källtext, inte den HTML som en renderare skulle producera. Det är avsiktligt. Två dokument kan rendera till identisk HTML och ändå ha källor med betydelsefulla skillnader, till exempel listpunkter skrivna med * mot - eller fetstil skriven med ** mot __. Diff på källnivå bevarar den signalen. Vill du se hur dokumentet renderas, klistra in det i din vanliga förhandsvisare: GitHubs webbgränssnitt, VS Code eller din statiska sajtgenerator.
En diff av renderad HTML säger vad läsarna kommer att se. En källdiff säger vad som faktiskt ändrades i filen. De svarar på olika frågor. För Markdown är källdiffen nästan alltid den mest användbara eftersom den troget visar författarens redigeringar: en rubriknivå ändrades från ## till ###, ett kodblock med staket bytte språktagg, en relativ länk blev absolut. Vill du ha jämförelse på HTML-nivå, kör båda filerna genom din renderare först och diffa utdatan.
Diffen själv parsar inte Markdown, så den bryr sig inte om vilken dialekt du använder. Tabeller, uppgiftslistor, genomstrykning och autolänkar ser bara ut som text. Smaken spelar roll när du frågar om dokumentet fortfarande renderas korrekt. CommonMark är det närmaste en basspecifikation, och GitHub Flavored Markdown är CommonMark plus tabeller, uppgiftslistor, genomstrykning och autolänkar. Välj det som din målrenderare stöder.
Frontmatter är bara text i toppen av filen, inramad av --- för YAML eller +++ för TOML. Statiska sajtgeneratorer som Hugo, Jekyll och MkDocs använder det för sidmetadata. Diffen behandlar blocket som vanlig text, så ändringar i title:, date: eller tags: dyker upp som vilken annan rad som helst. Om din frontmatter är stor och indragsberoende är vår YAML-diff-sida bättre lämpad för det blocket isolerat.
Ja. MDX är Markdown med inbäddade JSX-komponenter, och JSX är bara mer text ur diffens synvinkel. Du kan klistra in en .mdx-fil i någon av rutorna och diffen lyfter fram ändringar i importer, komponentprops och omkringliggande Markdown likadant som med .md. Det enda verktyget inte gör är att validera att din JSX kompilerar; det är MDX-kompilatorns jobb. För ren kodgranskning av JSX-bitarna, klistra in dem i vår text-diff.
Radslut är tecken, så en fil sparad med Windows-stilens CRLF och en fil sparad med Unix-stilens LF kommer att diffa olika på varje rad. Om dina rutor ser fulla av spökändringar ut är det nästan alltid orsaken. Lösningen är att normalisera båda filerna till samma radslut i din editor innan du klistrar in; i VS Code visas aktivt radslut i statusraden längst ner och byts med ett klick. Gits inställning core.autocrlf kan också införa överraskande CRLF-skillnader mellan maskiner.
Din Markdown lämnar aldrig din webbläsare. Editorn, diffen och formateraren körs alla på din maskin. Ingen analys av din indata, inga loggar, ingen serverresa. Bakgrundsläsning om själva formatet finns på Wikipedia, med den senaste CommonMark-specifikationen på spec.commonmark.org/0.31.2 och GitHub-smaken på github.github.com/gfm.