Text Diff online: twee teksten vergelijken met LCS/Myers + 6 cases
Een online text-diff-tool beantwoordt snel één vraag: wat is er veranderd tussen versie A en versie B? Je plakt twee blokken tekst, de tool draait een Longest Common Subsequence-algoritme, en je krijgt een side-by-side- of unified-weergave van elke invoeging, verwijdering en bewerking, meestal binnen een milliseconde.
Deze gids is voor developers die code reviewen, SRE’s die log-slices vergelijken, juristen die contracten redlinen en redacteuren die bewerkingen nalopen. Hij behandelt het algoritme (LCS, Myers, Patience), de twee standaardweergaven, de ignore-opties die 95% van de “alles ziet er veranderd uit”-klachten oplossen, wanneer je beter een JSON diff pakt, zes praktijkcases, en de valkuilen die het algoritme zelf verklaart.
Wil je meteen twee teksten vergelijken? Open Text Diff. Alles draait volledig in je browser, zonder upload.
1. Wat is een text diff?
Een text diff is de kleinste set invoegingen en verwijderingen die de ene tekst in de andere transformeert, waarbij elke regel als toegevoegd, verwijderd of ongewijzigd wordt gemarkeerd. Moderne diffs voegen een tweede pass op woord- of teken-niveau toe, zodat een eenletterige bewerking alleen die token markeert in plaats van de hele regel.
1.1 Waarom karaktergelijkheid (===) niet genoeg is
Voeg één regel toe bovenaan een config-bestand van 200 regels en een naïeve karaktervergelijking meldt elke byte na het invoegpunt als anders. De tekst is niet veranderd, alleen de positie. Een diff-algoritme moet herkennen dat “de volgende 199 regels nog steeds dezelfde regels zijn, alleen één plek opgeschoven” en één enkele invoeging rapporteren. Die herkenning is wat LCS je geeft, en daarom leveren git, GitHub en elke code-review-tool er een mee.
1.2 Side-by-side vs unified diff
Side-by-side zet de twee versies in parallelle kolommen en kleurt de cellen: groen voor toegevoegd, rood voor verwijderd, geel voor gewijzigd. Unified diff is het oudere tekstformaat uit GNU diff: één kolom, - en + markers, drie regels context rond elke hunk. Zelfde vergelijking, twee presentaties. Sectie 4 behandelt wanneer je welke gebruikt.
1.3 Waar text diff wordt gebruikt
Code review op GitHub en GitLab. Lokale git diff-output. Patches die in Slack worden geplakt. Contracten redlinen. Vertaalreview. CI-snapshottests die falen met +/--output. Tijdlijnonderzoek in logs. Twee .env-bestanden vergelijken. Alles waarbij twee tekstblobs regel voor regel gematcht moeten worden.
Open Text Diff en plak twee teksten om dit in actie te zien. Elke vergelijking draait lokaal in je browser.
2. Het algoritme achter text diff (LCS + Myers + Patience)
2.1 Longest Common Subsequence
Gegeven twee reeksen regels A en B is de Longest Common Subsequence de langste lijst regels die in beide voorkomt, in dezelfde volgorde, zonder dat ze direct naast elkaar hoeven te staan. Zodra je de LCS hebt, is de diff rechttoe rechtaan: regels in A maar niet in de LCS zijn verwijderd, regels in B maar niet in de LCS zijn toegevoegd, regels in de LCS zijn ongewijzigd.
Klassieke LCS draait als een dynamic-programming-tabel van formaat N × M. Cel (i, j) bevat de lengte van de LCS van de eerste i regels van A en de eerste j regels van B. Vul de tabel van links naar rechts, van boven naar beneden, loop dan terug vanuit de rechteronderhoek om het edit-script te reconstrueren. Tijd en ruimte zijn beide O(N×M): prima voor twee bestanden van duizend regels, traag voor een log van honderdduizend regels.
2.2 Myers (1986)
Eugene Myers’ paper uit 1986, “An O(ND) Difference Algorithm and Its Variations”, herformuleert het probleem als een kortste pad door een edit-graaf: nodes zijn posities (i, j) in de twee inputs, horizontale stappen zijn deletions, verticale stappen zijn insertions, diagonale stappen zijn matches. Het kortste pad is het minimale edit-script.
Myers draait in O((N+M)D), waarbij D de grootte van het edit-script is. Als de twee teksten op elkaar lijken (het gebruikelijke geval bij diffs) is D klein en is het algoritme bijna lineair. Het is de default in git diff, GNU diff en GitHub’s PR-renderer. Voor 99% van de web-inputs is het het juiste antwoord.
2.3 Patience diff (Bram Cohen, 2005)
Patience diff kiest een andere aanpak: vind regels die in elke input exact één keer voorkomen (genaamd “unique anchor lines”), match ze, en recurseer op de gaten tussen de ankers. De wiskunde is minder net (worst case blijft slecht), maar de output leest veel beter op code.
Waarom? Myers minimaliseert de edit-afstand, wat wiskundig optimaal is maar visueel slecht uitpakt wanneer de optimale uitlijning door ongerelateerde accolades of lege regels heen loopt. Patience weigert te aligneren op gemeenschappelijke boilerplate (elk bestand heeft }-regels, elk bestand heeft lege regels), waardoor functiegrenzen intact blijven. Bram Cohen vond het uit voor Bazaar; Git levert het als git diff --patience. Het nauw verwante Histogram-algoritme (git diff --histogram) is iets sneller met vergelijkbare outputkwaliteit.
Stel je twee versies van hetzelfde bestand voor waarin een functie is verplaatst. Myers lijnt mogelijk de sluitaccolade van functie A uit met de sluitaccolade van functie B en rapporteert de bodies als volledig verschillend. Patience verankert op de unieke functienamen en rapporteert een schone verplaatsing. Zelfde input, andere reviewervaring.
2.4 Algoritme-vergelijking
| Eigenschap | Myers (default) | Patience | Histogram |
|---|---|---|---|
| Tijdcomplexiteit | O((N+M)D) | ~O(N log N) common case | vergelijkbaar met Patience |
| Optimale edit-afstand | Ja, kortste script | Nee, kan langer zijn | Nee, kan langer zijn |
| Leest natuurlijk op code | Soms scheve uitlijning op accolades en lege regels | Uitstekend, verankert op unieke regels | Uitstekend |
| Gebruikt door | git default, GNU diff, GitHub UI | git diff --patience, Bazaar | git diff --histogram |
| Best voor | Snelheid en correctheid op de meeste inputs | Code reviews, refactor-diffs | Hetzelfde als Patience, iets sneller |
2.5 Wat deze tool doet
Text Diff gebruikt klassieke dynamic-programming-LCS met twee agressieve optimalisaties: gemeenschappelijke prefix- en suffix-trimming, en een tweede LCS-pass op token-niveau voor inline diff op woordniveau. Een diff van twee configs van tweeduizend regels met één gewijzigde regel klapt na trimming dicht tot een 1×1 DP-tabel en rendert binnen een milliseconde. Voor typische web-inputs is de keuze tussen Myers en DP onzichtbaar; beide finishen sneller dan de browser het resultaat kan tekenen.
3. Inline diff op woordniveau: waarom een wijziging van één teken de hele regel markeert
Je verandert één identifier op een regel en de hele regel licht rood en groen op. Bug? Nee, design.
De diff draait eerst LCS op regelniveau: “regel 14 is vervangen.” Dan draait hij voor elk vervangen paar een tweede LCS op token-niveau. Tokens worden geproduceerd door te splitsen op Unicode-woordgrenzen: reeksen letters en cijfers blijven samen, whitespace en interpunctie worden elk hun eigen token. De tweede LCS geeft je het minimale edit-script op token-niveau binnen die regel.
De renderer tekent de hele regel in de highlight-kleur zodat je oog hem vindt, en kleurt vervolgens alleen de gewijzigde tokens met de felle achtergrond. De ongewijzigde tokens eromheen krijgen een gedempte versie van dezelfde kleur: aanwezig, maar visueel rustig. Je oog landt op de exacte bewerking.
Voorbeeld 1: identifier-hernoeming. function getUser(id) wordt function getUser(userId). De hele regel is als gewijzigd gemarkeerd. Binnen de regel dragen alleen id (doorgestreept rood) en userId (fel groen) de inline highlight. Al het andere blijft gedempt.
Voorbeeld 2: log-latency-wijziging. POST /api/orders 201 88ms wordt POST /api/orders 201 4200ms. De regel is gewijzigd. Inline zijn alleen 88 en 4200 fel. Het pad, de methode en de statuscode blijven gedempt, precies wat iemand die een incidenttijdlijn leest nodig heeft.
Wanneer er te veel tokens veranderen, wordt highlighting op woordniveau ruis. De tool valt dan terug op een gepaarde remove + add-presentatie: de oorspronkelijke regel als verwijderd, de nieuwe regel als toegevoegd, geen inline-kleur. De drempel is ongeveer “meer dan de helft van de tokens verschilt.”
Diff op regelniveau vertelt je welke regel is veranderd; diff op woordniveau vertelt je welke tekens op die regel de wijziging dragen. Klik op Sample binnen Text Diff om beide weergaven op identieke input te zien.
4. Side-by-side vs unified diff: twee weergaven, één diff
4.1 Side-by-side-weergave
Twee kolommen: origineel links, gewijzigd rechts. Regels die matchen worden horizontaal uitgelijnd. Toegevoegde regels verschijnen alleen in de rechterkolom met een groene achtergrond; verwijderde regels alleen in de linkerkolom met een rode achtergrond; gewijzigde paren staan naast elkaar met een gele gutter en inline word-highlights.
Gebruik side-by-side wanneer een mens de diff gaat lezen: PR-review, lesgeven, demo’s, een contractwijziging doornemen met een niet-technische stakeholder. Het is de weergave voor menselijke ogen.
Het nadeel: hij reist niet mee. Je kunt een side-by-side-rendering niet in Slack plakken en iemand er iets mee laten doen. Je kunt hem niet doorpijpen naar patch. Voor delen en toepassen heb je unified nodig.
4.2 Unified diff-formaat
Unified diff is een platte-tekstformaat van vijftig jaar oud, gedefinieerd door GNU diff en gestandaardiseerd in POSIX. Een volledig voorbeeld:
--- original
+++ modified
@@ -1,3 +1,4 @@
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
+2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.De eerste twee regels benoemen de bronbestanden. De regel @@ -L,C +L,C @@ is een hunk-header: -L,C betekent dat er vanaf regel L van het origineel C regels betrokken zijn; +L,C zegt hetzelfde voor de gewijzigde versie. Binnen de hunk zijn regels die met een spatie beginnen context (ongewijzigd), - is verwijderd, + is toegevoegd.
Drie regels context boven en onder elke wijziging is de GNU-default. De meeste tools laten je dit aanpassen met -U n: diff -U0 voor geen context, diff -U10 voor tien regels. De hunk-header volgt wat je kiest.
In Text Diff klik je op de Unified-tab om van weergave te wisselen of op Copy unified diff om de patch naar je klembord te zetten.
4.3 Waar unified diff overal werkt
Unified diff reist mee. Het is het standaardformaat voor tekstuele wijzigingen.
| Bestemming | Accepteert unified diff? | Hoe |
|---|---|---|
GNU patch | Ja | patch -p1 < diff.patch |
git apply | Ja | git apply diff.patch |
| GitHub PR-review-comment | Ja (in een ```diff-blok) | Rendert met kleur |
| GitLab MR-comment | Ja | Zelfde fenced block |
| Bitbucket / Azure DevOps PR | Ja | Zelfde fenced block |
| Slack / Discord paste | Gedeeltelijk | Rendert als tekst in een codeblok, geen kleur |
| VS Code “Open Patch” | Ja | Patch toepassen via Source Control |
| Jira / Linear issue body | Gedeeltelijk | Werkt in een codeblok, geen apply-knop |
Dezelfde negen regels ---/+++/@@-tekst werken op patch, op git apply, renderen in drie PR-platforms en overleven een Slack-paste. Geen ander diff-formaat komt zelfs maar in de buurt van dat bereik.
4.4 Wanneer kies je welke
Side-by-side voor review, unified voor delen en toepassen. Als jij zelf de diff leest, zijn de kolommen sneller. Als iemand of iets verderop hem moet consumeren (een reviewer, een tool, een patch-command), kopieer dan het unified-formaat.
5. Ignore-opties: whitespace, hoofdletters, lege regels, regeleinden
De meeste “alles ziet er veranderd uit”-klachten zijn ruis. Vier toggles lossen daar 95% van op.
- Ignore case zet
Agelijk aana. Equivalent aangit diff -i. Gebruik dit voor omgevingsvariabelen-vergelijkingen, SQL-keyword-style-audits, overal waar de conventie hoofdletters tegenover kleine letters is maar de betekenis identiek. - Ignore all whitespace klapt elke spatie, tab en newline samen vóór vergelijking. Equivalent aan
git diff -w. Het antwoord op tabs ↔ spaces-reformattering, indentatie-herwerken en “we zijn overgestapt op Prettier”-diffs die de regelaantallen vernielen. Een ignore-whitespace-diff op die wijzigingen gaat doorgaans van 87 modificaties naar 4. - Ignore trailing spaces and tabs strijkt alleen end-of-line-whitespace weg. Equivalent aan
git diff -b. Het antwoord op CRLF-ruis na kopiëren tussen Windows- en Unix-machines: de afsluitende\r-tekens worden eruit gefilterd en de echte content lijnt op. - Ignore blank lines laat lege regels vallen vóór het diffen. Het antwoord op “ik heb één alinea-onderbreking toegevoegd en nu ziet alinea 12 er compleet anders uit” bij proza-diffs.
Een config van 200 regels die “87 modificaties” rapporteert, zakt meestal tot “4 modificaties” na Ignore all whitespace. Een Windows-naar-Unix-kopie die elke regel markeert, zakt naar nul met Ignore trailing spaces. Elke toggle is onafhankelijk en blijft tussen sessies bewaard.
CRLF vs LF. Windows-regeleinden zijn \r\n; Unix is \n; klassieke Mac is \r. Open een Windows-bestand in een Unix-editor die niet normaliseert en de afsluitende \r blijft staan. Elke regel zal diff’en als “de content matcht maar er staat een \r aan het eind.” Ignore trailing spaces dempt dit zonder echte wijzigingen te verbergen.
Eén waarschuwing. Ignore-opties zijn tweesnijdend. Zet Ignore case aan en een refactor die LOG.error in log.Error verandert, ziet er identiek uit. Zet Ignore all whitespace aan en een Python-indentatiebug wordt onzichtbaar. Kies de toggles die passen bij de vraag die je stelt, en zet ze weer uit als je klaar bent.
6. Text diff vs JSON diff vs git diff: beslismatrix
Text diff is matchen op regel en woord zonder begrip van structuur. Dat is precies wat je wilt voor proza en precies wat je niet wilt voor JSON.
6.1 Beslismatrix
| Inputtype | Text diff | JSON diff | Git diff |
|---|---|---|---|
| Proza / Markdown / contract | Best | Verkeerde tool | Gedeeltelijk (werkt alleen op getrackte bestanden) |
| Code-snippet (één bestand geplakt) | Best | Verkeerde tool | Gedeeltelijk (heeft repo nodig) |
| Code in een repo (meerdere bestanden) | Gedeeltelijk | Verkeerde tool | Best |
| API JSON-response | Verkeerde tool (false positives op key-volgorde) | Best | Verkeerde tool |
| YAML / TOML-config | Gedeeltelijk (false positives op key-volgorde) | Best (na conversie) | Gedeeltelijk |
| CSV regel voor regel | Gedeeltelijk | Verkeerde tool | Verkeerde tool |
| Log / heredoc | Best | Verkeerde tool | Verkeerde tool |
| Binair bestand | Verkeerde tool | Verkeerde tool | git diff --binary |
6.2 Wanneer text diff de verkeerde tool is
Drie klassieke fouten.
JSON met geherordende keys. {"a":1,"b":2} en {"b":2,"a":1} zijn hetzelfde JSON-document. Een text diff rapporteert elke regel als gewijzigd omdat het echt verschillende regels zijn. Gebruik JSON Diff, die begrijpt dat JSON-keys ongeordend zijn.
YAML-configs die geherformatteerd zijn. Wijzig één waarde, draai het bestand door een formatter, en indentatie, key-volgorde en quoting verschuiven allemaal. Text diff rapporteert een volledige herschrijving. Converteer beide bestanden eerst naar JSON, vergelijk dan met JSON Diff.
Multi-file-refactors met renames. Git tracket renames; text diff niet. Als je twee bomen vergelijkt door bestanden te concateneren tot één blob, verschijnt elke verplaatsing tussen bestanden als removed + added. Gebruik dan git diff (of git diff --find-renames=80%).
6.3 Wanneer text diff precies goed is
Proza. Code-snippets geplakt vanaf overal. Contract-redlines. Log-slices. Vertaalreview waarbij je natural-language-zinnen matcht. .env-bestanden waar volgorde ertoe doet omdat shells ze van boven naar beneden lezen. Alles waarbij de regels zelf de betekenis dragen.
Voor de deep dive over ruis filteren uit JSON-diffs (timestamps, request-ID’s, automatisch gegenereerde UUID’s) lees Tijdstempels en ID’s negeren bij JSON Diff.
7. Zes praktijkvoorbeelden (met direct bruikbare input)
7.1 Code-review-snippet: functienaam veranderen
Je reviewt een PR. De auteur heeft id hernoemd naar userId en een guard-clause toegevoegd. Plak beide versies:
// Original
function getUser(id) {
const u = db.users.find(x => x.id === id);
return u;
}// Modified
function getUser(userId) {
if (!userId) return null;
const u = db.users.find(x => x.id === userId);
return u;
}De diff toont drie gewijzigde regels plus één toegevoegde regel. Inline word-highlighting markeert elke id → userId-token; de nieuwe guard-clause verschijnt met een groene achtergrond. Zet de ignore-opties uit. Probeer dit in Text Diff en kopieer de unified-output als review-comment.
7.2 Contract- of beleidsredline: één ingevoegde clausule
Vijftig alinea’s contract, één ingevoegde clausule. Plak de versie van gisteren links en die van vandaag rechts:
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
3. Disputes are resolved in California courts.1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.De diff rendert negenenveertig ongewijzigde regels en één toegevoegde regel (+2a. Termination notice must be in writing.). Exporteer de unified diff als juridisch reviewspoor.
7.3 Tijdlijnonderzoek in logs
Je vermoedt een latency-regressie. Pak een slice access-logs van vóór en tijdens het incident:
GET /api/users 200 14ms
POST /api/orders 201 88ms
GET /api/orders/42 200 21msGET /api/users 200 14ms
POST /api/orders 201 4200ms
GET /api/orders/42 500 21msInline highlight brengt 88 → 4200 aan het licht (een 50× latency-sprong) en 200 → 500 (een order-detail-endpoint dat begon te falen). Voor rijker logwerk (velden trekken, groeperen per endpoint, percentielen berekenen) combineer je de diff met jq spiekbriefje als je logs JSON zijn.
7.4 Vertaalreview: placeholders behouden
Je hebt een nieuw vertaalbureau ingehuurd en wilt verifiëren dat de nieuwe copy structureel matcht met de oude. Plak de oude vertaling links, de nieuwe rechts. Zet Ignore trailing spaces / tabs aan, want vertalers voegen routinematig een verdwaalde spatie toe aan het eind van strings.
De diff bevestigt dat elke {username}, {count} en %s-placeholder op zijn plek blijft; alleen de natural-language-tekst verandert. Een ontbrekende placeholder duikt op als een verwijderde token in de inline diff, opgevangen voordat je live gaat. Als je de placeholder-formaten zelf moet vergelijken, dekt het Regex Spiekbriefje \{\w+\} en consorten. Probeer dit in Text Diff.
7.5 Config- of .env-audit: productie vs staging
Vergelijk twee .env-bestanden. Zet Ignore blank lines aan zodat alinea-stijl-groepering geen secties scheef trekt. De diff laat zien welke keys verschillen van waarde, welke keys in de ene omgeving bestaan maar niet in de andere, en waar comments uit de pas zijn gaan lopen. Vijf minuten die de “het werkt op staging maar niet in productie”-debug-sessie voorkomen.
7.6 Proza- of conceptrevisie
Je redacteur stuurde een concept terug. Plak je origineel links en de bewerkte versie rechts. Inline word-diff toont precies welke zinnen herschreven zijn, welke onaangeroerd bleven en welke alinea’s zijn ingevoegd. Accepteer of verwerp wijzigingen één voor één, zonder Track Changes-feature, zonder Word-bestand, zonder proprietary formaat.
8. Veelvoorkomende valkuilen en hoe je ze als symptoom leest
Algoritme-gedrag verklaart de meeste gebruikerspijn. Vijf veelgehoorde klachten en wat ze betekenen.
Valkuil 1: “Elke regel is rood na een Windows-naar-Unix-kopie.” Symptoom: elke regel in de diff toont als gewijzigd terwijl de content er identiek uitziet. Oorzaak: afsluitende \r-tekens uit CRLF-regeleinden. Fix: zet Ignore trailing spaces / tabs aan. De diff zakt naar de echte wijzigingen.
Valkuil 2: “Ik plakte JSON en 100% van de regels is anders.” Symptoom: twee JSON-objecten die equivalent zouden moeten zijn, tonen als volledig gewijzigd. Oorzaak: herordende keys. Text diff behandelt regelvolgorde als significant; JSON niet. Fix: gebruik JSON Diff voor elke JSON-input.
Valkuil 3: “Tabs ↔ spaces reformatteren heeft de diff opgeblazen.” Symptoom: 87 modificaties, allemaal indentatie. Oorzaak: je formatter heeft de leidende whitespace van elke regel veranderd. Fix: Ignore all whitespace klapt de ruis dicht en haalt de echte semantische wijzigingen naar boven.
Valkuil 4: “Diff zegt identiek maar cmp is het er niet mee eens.” Symptoom: de diff rapporteert geen verschillen, maar een vergelijking op byte-niveau zegt dat de bestanden verschillen. Oorzaak: een ignore-optie uit een eerdere sessie staat nog aan en maskeert echte wijzigingen. Fix: open het Ignore-options-paneel en zet elke toggle uit, en diff opnieuw.
Valkuil 5: “Eén korte bewerking verschijnt als remove + add.” Symptoom: een kleine wijziging verschijnt als losse verwijderde regel en losse toegevoegde regel in plaats van een inline highlight. Oorzaak: het aandeel gewijzigde tokens kruiste de inline-drempel en de renderer viel terug op de gepaarde-regel-presentatie. Dat is bedoeld gedrag, geen bug. Wissel naar de Unified-weergave om het klassieke -/+-paar te zien dat patch-tools verwachten.
9. Privacy, performance en wanneer je de commandoregel pakt
Elke vergelijking in Text Diff draait in JavaScript binnen je browser. Geen upload, geen tijdelijk bestand, geen serverlog, geen analytics op de tekst die je plakt. Veilig voor proprietary code, interne contracten, privélogs en alles wat je niet in een server van een derde zou plakken.
Praktische limieten: ongeveer 5.000 regels of 1 MB per kant. Live diff schakelt boven 200 KB gecombineerd uit en stapt over op een handmatige Diff-knop, zodat typen de pagina niet blokkeert. Boven 5.000 regels wordt de input afgekapt en verschijnt er een waarschuwing. De limieten bestaan omdat de diff op de main thread draait (geen web worker), en een worker-overdracht plus serialisatie zou meer kosten dan de diff zelf bij kleine inputs.
Wanneer je input te groot wordt voor de browser, stap je over op de commandoregel:
# Unified diff tussen twee bestanden
diff -u a.txt b.txt
# Hetzelfde, maar met git's diff-engine (Patience, Histogram, kleur)
git diff --no-index a.txt b.txt
git diff --no-index --patience a.txt b.txt
# Streaming diff-viewer voor enorme bestanden (Rust, side-by-side, syntax-aware)
delta a.txt b.txtPak de commandoregel voor multi-megabyte-logs, binaire bestanden, multi-file-repository-diffs, situaties waarbij je syntax-aware kleuring zoals delta wilt, of waar je diff-output door een andere tool moet pijpen.
10. Unicode, CJK en RTL: internationale text-diff-notities
De tokenizer splitst op Unicode-woordgrenzen met drie categorieën: word-runs (\p{L}-letters en \p{N}-cijfers), niet-word-interpunctie en whitespace. Elke categorie produceert eigen tokens, dus hello, world! wordt hello, ,, , world, !: vijf tokens.
Voor CJK-content (Chinees, Japans, Koreaans) is elk ideograaf of kana een eigen token. Verander één teken in een Chinese zin en alleen dat teken draagt de inline highlight, terwijl de rest van de regel gedempt blijft. Alineastructuur blijft regel-gebaseerd, dus een zin-herschrijving die een regelafbreking toevoegt verschijnt als bewerking op regelniveau, niet op token-niveau.
Voor RTL-talen (Arabisch, Hebreeuws) gebruikt de diff logische CSS-richtingen (ms-, me- in plaats van ml-, mr-). Op RTL-locales flipt de gutter- en regelkolom vanzelf; binnen elke diff-cel volgt de tekstrichting de content, dus Arabische strings renderen rechts-naar-links terwijl de +- en --markers uitgelijnd blijven op de start-gutter.
Normalisatie van regeleinden herkent \r\n (Windows), \n (Unix) en kale \r (oude Mac OS tot en met versie 9). Alle drie splitsen als losse regels, zodat een bestand dat van het ene platform naar het andere is geconverteerd niet samenklapt tot één megaregel.
11. FAQ
Hoe werkt een online text diff?
Een text diff splitst beide inputs in regels, draait een Longest Common Subsequence-algoritme (meestal Myers’ O((N+M)D)) om de kleinste set invoegingen en verwijderingen te vinden, en markeert dan toegevoegde (groen), verwijderde (rood) en ongewijzigde (grijs) regels. Een tweede LCS op token-niveau markeert de gewijzigde woorden binnen elke gewijzigde regel. Text Diff draait de hele vergelijking lokaal in je browser.
Wat is het verschil tussen text diff en JSON diff?
Text diff vergelijkt regel voor regel, ideaal voor proza, code, logs en contracten. JSON Diff begrijpt JSON’s datamodel: key-volgorde doet er niet toe, types zijn strikt (1 ≠ "1"), arrays kunnen op key gematcht worden. Plak JSON in een text diff en key-herordeningen of whitespace duiken op als wijzigingen die JSON Diff negeert. Gebruik text diff voor ongestructureerde content, JSON Diff voor API-responses en configs.
Waarom toont de diff hele regels als gewijzigd als ik maar één woord heb bewerkt?
Dat doet hij niet. De regel wordt gemarkeerd omdat er iets op is veranderd, maar binnen de markering dragen alleen de gewijzigde tokens de felle achtergrond (groen voor toegevoegd, rood doorgestreept voor verwijderd). Dit is inline diff op woordniveau: regelcontext blijft leesbaar terwijl je oog op de exacte bewerking landt. Wanneer er te veel van een regel is veranderd voor zinvolle highlighting op woordniveau, valt de diff terug op een los remove + add-paar zodat de structuur netjes blijft.
Hoe negeer ik whitespace, hoofdletters of lege regels in de diff?
Schakel het Ignore-options-paneel. Ignore case maakt A en a gelijk. Ignore all whitespace klapt elke spatie, tab en newline samen, equivalent aan git diff -w. Ignore trailing spaces and tabs spiegelt git diff -b en dempt CRLF-ruis. Ignore blank lines laat lege regels vallen zodat alinea-herspatiëring de diff niet meer scheeftrekt. Elke optie is onafhankelijk en blijft tussen sessies bewaard.
Wat is unified diff-formaat?
Unified diff is het ---/+++/@@ -L,C +L,C @@-tekstformaat dat eind jaren tachtig door GNU diff is geïntroduceerd en gebruikt wordt door git, GitHub, GitLab en het Unix-commando patch. Elke hunk toont drie context-regels rond de wijziging, met - voor verwijderd en + voor toegevoegd. Plak unified-output in een PR-comment, in git apply, of draai patch -p1 < diff.patch; hij past schoon toe.
Myers vs Patience: welk diff-algoritme is beter voor code review?
Myers is de default in git diff en GNU diff: snel en wiskundig minimaal, maar lijnt soms ongerelateerde lege regels of sluitaccolades uit, wat diffs oplevert die “raar lezen.” Patience (Bram Cohen, 2005) verankert op regels die in elke input exact één keer voorkomen en recurseert tussen ankers, zodat functiegrenzen intact blijven. Gebruik git diff --patience (of --histogram voor vergelijkbare resultaten, iets sneller) bij het reviewen van refactors.
Wordt de tekst die ik plak naar een server gestuurd?
Nee. Elke vergelijking in Text Diff draait lokaal in JavaScript binnen je browser. Je tekst wordt nooit geüpload, gelogd, op schijf opgeslagen of naar een derde partij gestuurd. Alleen je UI-voorkeuren (weergavemodus en ignore-toggles) worden in localStorage opgeslagen, zodat de pagina ze bij je volgende bezoek onthoudt; nooit de tekst. Verifieer met DevTools → Network: nul requests vuren wanneer je op Diff klikt.
Hoe groot kunnen de twee inputs zijn?
De praktische limiet is ongeveer 5.000 regels of 1 MB per kant. Live diff schakelt boven 200 KB gecombineerd uit en stapt over op een handmatige Diff-knop. Boven 5.000 regels wordt de input afgekapt met een waarschuwing. Voor multi-megabyte-bestanden stap je over op diff -u a.txt b.txt, git diff --no-index a.txt b.txt of delta: die streamen en kunnen gigabytes aan.