Text Diff online: zwei Texte vergleichen mit LCS/Myers + 6 Praxisfälle

Ein Text-Diff-Tool im Browser beantwortet eine einzige Frage in Sekundenbruchteilen: Was hat sich zwischen Version A und Version B tatsächlich geändert? Sie fügen zwei Textblöcke ein, das Werkzeug fährt einen LCS-Algorithmus (Longest Common Subsequence), und Sie erhalten eine Side-by-Side- oder Unified-Ansicht jeder Einfügung, Löschung und Änderung, in der Regel unter einer Millisekunde.

Dieser Leitfaden richtet sich an Entwicklerinnen und Entwickler bei Code Reviews, an SREs beim Vergleich von Log-Ausschnitten, an Jurist:innen beim Redlining von Verträgen und an Autor:innen beim Sichten von Lektoratsfassungen. Behandelt werden Algorithmus (LCS, Myers, Patience), die beiden Standardansichten, die Ignore-Schalter, die 95 % aller „alles sieht geändert aus”-Klagen beseitigen, wann besser ein JSON-Diff zum Einsatz kommt, sechs Copy-and-paste-Praxisfälle sowie die Stolperfallen, die sich aus dem Algorithmus selbst erklären lassen.

Sie möchten direkt zwei Texte vergleichen? Öffnen Sie Text Diff. Alles läuft in Ihrem Browser, ohne Upload.

1. Was ist ein Text Diff?

Ein Text Diff ist die kleinste Menge an Einfügungen und Löschungen, die einen Text in einen anderen überführt; jede Zeile wird als hinzugefügt, entfernt oder unverändert markiert. Moderne Diffs ergänzen einen zweiten Durchlauf auf Wort- oder Zeichenebene, sodass eine Ein-Zeichen-Änderung nur das betroffene Token hervorhebt statt der ganzen Zeile.

1.1 Warum Zeichengleichheit (===) nicht ausreicht

Fügen Sie eine Zeile oben in eine 200-Zeilen-Konfigurationsdatei ein, und ein naiver Zeichenvergleich meldet jedes einzelne Byte nach der Einfügestelle als unterschiedlich. Der Text hat sich nicht verändert, nur seine Position. Ein Diff-Algorithmus muss erkennen: „Die nächsten 199 Zeilen sind weiterhin dieselben Zeilen, nur um eine Position verschoben”, und genau eine Einfügung melden. Diese Erkenntnis liefert LCS, und deshalb hat git, GitHub und jedes Code-Review-Tool genau das an Bord.

1.2 Side-by-Side vs Unified Diff

Side-by-Side stellt die beiden Versionen in parallelen Spalten dar und färbt die Zellen ein: Grün für hinzugefügt, Rot für entfernt, Gelb für geändert. Der Unified Diff ist das ältere Textformat aus GNU diff: eine Spalte, -- und +-Markierungen, drei Kontextzeilen rund um jeden Hunk. Gleicher Vergleich, zwei Darstellungen. Abschnitt 4 zeigt, wann welche Ansicht passt.

1.3 Wo Text Diff zum Einsatz kommt

Code Review auf GitHub und GitLab. Lokale Ausgabe von git diff. In Slack eingefügte Patches. Vertrags-Redlining. Übersetzungsreview. CI-Snapshot-Tests, die mit +/--Ausgabe fehlschlagen. Untersuchung von Log-Zeitachsen. Vergleich zweier .env-Dateien. Überall dort, wo zwei Textblöcke Zeile für Zeile abgeglichen werden müssen.

Öffnen Sie Text Diff und fügen Sie zwei Texte ein, um all das in Aktion zu sehen. Jeder Vergleich läuft lokal in Ihrem Browser.

2. Der Algorithmus hinter Text Diff (LCS + Myers + Patience)

2.1 Longest Common Subsequence

Gegeben zwei Zeilenfolgen A und B, ist die Longest Common Subsequence die längste Liste von Zeilen, die in beiden in derselben Reihenfolge vorkommen (ohne Adjazenzforderung). Hat man die LCS, ergibt sich das Diff direkt: Zeilen aus A, die nicht in der LCS stehen, sind entfernt; Zeilen aus B, die nicht in der LCS stehen, sind hinzugefügt; Zeilen in der LCS sind unverändert.

Das klassische LCS läuft als Dynamic-Programming-Tabelle der Größe N × M. Zelle (i, j) enthält die Länge der LCS der ersten i Zeilen von A und der ersten j Zeilen von B. Die Tabelle wird von links nach rechts und von oben nach unten gefüllt; anschließend läuft man von der rechten unteren Zelle rückwärts, um das Edit-Skript zu rekonstruieren. Zeit- und Speicherkomplexität liegen bei O(N×M): passend für zwei Dateien mit je tausend Zeilen, träge bei einem Log mit hunderttausend Zeilen.

2.2 Myers (1986)

Eugene Myers’ Aufsatz von 1986 „An O(ND) Difference Algorithm and Its Variations” formuliert das Problem als kürzesten Pfad durch einen Edit-Graphen um: Knoten sind Positionen (i, j) in den beiden Eingaben, horizontale Schritte sind Löschungen, vertikale Schritte Einfügungen, diagonale Schritte Übereinstimmungen. Der kürzeste Pfad ist das minimale Edit-Skript.

Myers läuft in O((N+M)D), wobei D die Größe des Edit-Skripts ist. Wenn die beiden Texte ähnlich sind (der typische Fall beim Diffen), ist D klein und der Algorithmus de facto linear. Er ist der Standard in git diff, GNU diff und dem PR-Renderer von GitHub. Für neunundneunzig Prozent aller Web-Eingaben ist er die richtige Wahl.

2.3 Patience Diff (Bram Cohen, 2005)

Patience Diff wählt einen anderen Weg: Finde Zeilen, die in jeder Eingabe genau einmal vorkommen (sogenannte „unique anchor lines”), gleiche sie ab und rekursiere zwischen den Ankern. Die Mathematik ist unsauberer (der Worst Case bleibt schlecht), doch die Ausgabe liest sich auf Code deutlich besser.

Warum? Myers minimiert die Edit-Distanz: mathematisch optimal, visuell aber grausam, wenn die optimale Ausrichtung unverwandte geschweifte Klammern oder Leerzeilen überquert. Patience verweigert die Ausrichtung auf gängigem Boilerplate (jede Datei hat }-Zeilen, jede Datei hat Leerzeilen), wodurch Funktionsgrenzen erhalten bleiben. Bram Cohen erfand das Verfahren für Bazaar; Git liefert es als git diff --patience aus. Der eng verwandte Histogram-Algorithmus (git diff --histogram) ist etwas schneller bei vergleichbarer Ausgabequalität.

Stellen Sie sich zwei Versionen derselben Datei vor, bei denen eine Funktion umgezogen ist. Myers richtet eventuell die schließende Klammer von Funktion A an der schließenden Klammer von Funktion B aus und meldet beide Funktionskörper als völlig verschieden. Patience verankert sich an den eindeutigen Funktionsnamen und meldet einen sauberen Umzug. Gleiche Eingabe, sehr unterschiedliches Reviewerlebnis.

2.4 Algorithmusvergleich

Eigenschaft	Myers (Standard)	Patience	Histogram
Zeitkomplexität	O((N+M)D)	~O(N log N) im Regelfall	ähnlich Patience
Optimale Edit-Distanz	Ja, kürzestes Skript	Nein, kann länger sein	Nein, kann länger sein
Liest sich natürlich auf Code	Manchmal Fehlausrichtung an Klammern und Leerzeilen	Hervorragend, verankert sich an eindeutigen Zeilen	Hervorragend
Verwendet von	git-Standard, GNU diff, GitHub-UI	git diff --patience, Bazaar	git diff --histogram
Am besten für	Geschwindigkeit und Korrektheit auf den meisten Eingaben	Code Reviews, Refactor-Diffs	Wie Patience, etwas schneller

2.5 Was dieses Tool tut

Text Diff verwendet klassisches LCS per Dynamic Programming mit zwei aggressiven Optimierungen: Beschneiden gemeinsamer Präfixe und Suffixe sowie ein zweiter Token-LCS-Durchlauf für den Inline-Worttausch-Diff. Ein Diff zweier 2000-Zeilen-Konfigurationen mit einer geänderten Zeile schrumpft nach dem Trimmen auf eine 1×1-DP-Tabelle und rendert in unter einer Millisekunde. Für typische Web-Eingaben ist die Wahl zwischen Myers und DP unsichtbar; beide sind schneller fertig, als der Browser das Ergebnis zeichnen kann.

3. Inline-Worttausch-Diff: warum eine Ein-Zeichen-Änderung die ganze Zeile hervorhebt

Sie ändern einen Bezeichner in einer Zeile, und die komplette Zeile leuchtet rot und grün. Bug? Nein, Absicht.

Das Diff fährt zuerst LCS auf Zeilenebene: „Zeile 14 wurde ersetzt.” Dann läuft für jedes ersetzte Paar ein zweites LCS auf Tokenebene. Tokens entstehen durch Splitten an Unicode-Wortgrenzen: Folgen aus Buchstaben und Ziffern bleiben zusammen, Whitespace und Interpunktion werden jeweils zu eigenen Tokens. Das zweite LCS liefert das minimale Token-Edit-Skript innerhalb dieser Zeile.

Der Renderer zeichnet die gesamte Zeile in der Hervorhebungsfarbe, damit Ihr Blick sie findet, färbt dann aber nur die geänderten Tokens mit dem hellen Hintergrund. Die unveränderten Tokens drumherum tragen eine gedimmte Variante derselben Farbe, sichtbar, aber visuell ruhig. Ihr Auge landet exakt auf der Änderung.

Beispiel 1: Bezeichner-Umbenennung. function getUser(id) wird zu function getUser(userId). Die gesamte Zeile gilt als geändert. Innerhalb der Zeile tragen nur id (durchgestrichen, rot) und userId (leuchtend grün) die Inline-Hervorhebung. Alles andere bleibt gedimmt.

Beispiel 2: Latenzänderung im Log. POST /api/orders 201 88ms wird zu POST /api/orders 201 4200ms. Die Zeile ist geändert. Inline leuchten nur 88 und 4200. Pfad, Methode und Statuscode bleiben gedimmt, genau das, was man bei der Analyse einer Vorfall-Timeline braucht.

Wenn zu viele Tokens wechseln, wird Wort-Highlighting zum Rauschen. Das Tool fällt dann auf eine Paardarstellung aus Entfernen plus Hinzufügen zurück: Die Originalzeile als entfernt, die neue Zeile als hinzugefügt, ohne Inline-Färbung. Die Schwelle liegt grob bei „mehr als die Hälfte der Tokens unterscheidet sich”.

Kurz gesagt: Der Zeilen-Diff sagt Ihnen, welche Zeile sich geändert hat; der Wort-Diff sagt Ihnen, welche Zeichen in dieser Zeile die Änderung tragen. Klicken Sie in Text Diff auf Sample, um beide Ansichten auf identischer Eingabe zu sehen.

4. Side-by-Side vs Unified Diff: zwei Ansichten, ein Diff

4.1 Side-by-Side-Ansicht

Zwei Spalten: Original links, geänderte Fassung rechts. Übereinstimmende Zeilen werden horizontal ausgerichtet. Hinzugefügte Zeilen erscheinen nur rechts mit grünem Hintergrund; entfernte Zeilen nur links mit rotem Hintergrund; geänderte Paare stehen nebeneinander mit einer gelben Gutter und Inline-Worthervorhebungen.

Verwenden Sie Side-by-Side, wenn ein Mensch den Diff liest: PR-Review, Unterricht, Demo, das Durchgehen einer Vertragsänderung mit nicht-technischen Stakeholdern. Das ist die Ansicht für die Augen.

Der Nachteil: Sie ist nicht transportfähig. Eine Side-by-Side-Darstellung lässt sich nicht in Slack einfügen und niemand kann sie anwenden. Sie können sie nicht an patch pipen. Zum Teilen und Anwenden brauchen Sie das Unified-Format.

4.2 Unified-Diff-Format

Der Unified Diff ist ein lang etabliertes Plaintext-Format, definiert durch GNU diff und standardisiert in POSIX. Ein vollständiges Beispiel:

--- 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.

Die ersten beiden Zeilen benennen die Quelldateien. Die Zeile @@ -L,C +L,C @@ ist ein Hunk-Header: -L,C bedeutet, dass ab Zeile L des Originals C Zeilen betroffen sind; +L,C sagt dasselbe für die geänderte Fassung. Innerhalb des Hunks markieren Zeilen mit führendem Leerzeichen den Kontext (unverändert), - steht für entfernt, + für hinzugefügt.

Drei Kontextzeilen ober- und unterhalb jeder Änderung sind der GNU-Standard. Die meisten Werkzeuge lassen sich mit -U n umstellen: diff -U0 ohne Kontext, diff -U10 mit zehn Zeilen. Der Hunk-Header passt sich an, was immer Sie wählen.

In Text Diff wechseln Sie über den Tab „Unified” die Ansicht oder klicken auf Copy unified diff, um den Patch in die Zwischenablage zu legen.

4.3 Wo Unified Diff portabel ist

Unified Diff lässt sich überall einsetzen. Er ist das de-facto-Format für den Austausch textueller Änderungen.

Ziel	Akzeptiert Unified Diff?	Wie
GNU patch	Ja	patch -p1 < diff.patch
git apply	Ja	git apply diff.patch
GitHub-PR-Review-Kommentar	Ja (in einem ```diff-Block)	Rendert mit Farbe
GitLab-MR-Kommentar	Ja	Gleicher Fenced Block
Bitbucket / Azure DevOps PR	Ja	Gleicher Fenced Block
Slack-/Discord-Einfügung	Teilweise	Rendert als Text in einem Codeblock, ohne Farbe
VS Code „Open Patch”	Ja	Patch via Source Control anwenden
Jira-/Linear-Issue-Body	Teilweise	Funktioniert im Codeblock, kein Apply-Button

Dieselben neun Zeilen aus ---/+++/@@ funktionieren mit patch, mit git apply, rendern in drei PR-Plattformen und überleben das Einfügen in Slack. Kein anderes Diff-Format hat eine vergleichbare Reichweite.

4.4 Wann welche Ansicht

Side-by-Side fürs Review, Unified fürs Teilen und Anwenden. Wenn Sie den Diff selbst lesen, sind die Spalten schneller. Wenn weiter unten in der Kette etwas oder jemand ihn konsumieren soll (eine Reviewerin, ein Tool, ein Patch-Befehl), kopieren Sie das Unified-Format.

5. Ignore-Optionen: Whitespace, Groß-/Kleinschreibung, Leerzeilen, Zeilenumbrüche

Die meisten „alles sieht geändert aus”-Klagen sind Rauschen. Vier Schalter beheben 95 % davon.

1. Groß-/Kleinschreibung ignorieren bildet A auf a ab. Äquivalent zu git diff -i. Nützlich bei Vergleichen von Umgebungsvariablen, bei Style-Audits für SQL-Schlüsselwörter, überall dort, wo die Konvention zwischen Lautstark-Großschreibung und gedämpfter Kleinschreibung schwankt, die Bedeutung aber identisch bleibt.
2. Sämtliche Whitespaces ignorieren kollabiert jedes Leerzeichen, jeden Tab und jeden Zeilenumbruch vor dem Vergleich. Äquivalent zu git diff -w. Das Heilmittel gegen Tabs ↔ Spaces, Reindentation und „wir sind auf Prettier umgestiegen”-Diffs, die jede Zeilenzählung zerstören. Ein Diff mit ignoriertem Whitespace fällt bei solchen Änderungen typischerweise von 87 Modifikationen auf 4.
3. Trailing Spaces und Tabs ignorieren entfernt nur Whitespace am Zeilenende. Äquivalent zu git diff -b. Das Heilmittel gegen CRLF-Rauschen nach dem Kopieren zwischen Windows und Unix: die angehängten \r-Zeichen werden herausgefiltert und der eigentliche Inhalt richtet sich aus.
4. Leerzeilen ignorieren wirft leere Zeilen vor dem Diff. Das Heilmittel gegen „Ich habe einen Absatzumbruch eingefügt und plötzlich sieht Absatz 12 völlig anders aus” bei Prosa-Diffs.

Eine 200-Zeilen-Konfiguration, die „87 Modifikationen” meldet, fällt nach „Sämtliche Whitespaces ignorieren” üblicherweise auf „4 Modifikationen”. Eine Windows-zu-Unix-Kopie, die jede Zeile markiert, fällt mit „Trailing Spaces ignorieren” auf null. Jeder Schalter ist unabhängig und überdauert die Sitzung.

CRLF vs LF. Windows-Zeilenumbrüche sind \r\n, Unix ist \n, klassisches Mac ist \r. Öffnen Sie eine Windows-Datei in einem Unix-Editor, der nicht normalisiert, bleibt das \r erhalten. Jede Zeile wird im Diff erscheinen als „Inhalt stimmt, aber am Ende steht ein \r”. „Trailing Spaces ignorieren” bringt diese Stille zurück, ohne echte Änderungen zu verschlucken.

Eine Warnung. Ignore-Optionen sind zweischneidig. Aktivieren Sie „Groß-/Kleinschreibung ignorieren” und ein Refactor, der LOG.error zu log.Error umbenennt, sieht identisch aus. Aktivieren Sie „Sämtliche Whitespaces ignorieren”, und ein Python-Einrückungsbug wird unsichtbar. Wählen Sie die Schalter passend zu der Frage, die Sie stellen, und schalten Sie sie danach wieder ab.

6. Text Diff vs JSON Diff vs Git Diff: Entscheidungsmatrix

Text Diff ist Zeilen- und Wortabgleich ohne strukturelles Verständnis. Genau das wollen Sie bei Prosa, und genau das wollen Sie nicht bei JSON.

6.1 Entscheidungsmatrix

Eingabetyp	Text Diff	JSON Diff	Git Diff
Prosa / Markdown / Vertrag	Beste Wahl	Falsches Werkzeug	Teilweise (nur auf getrackten Dateien)
Code-Snippet (Einzeldatei-Einfügung)	Beste Wahl	Falsches Werkzeug	Teilweise (braucht ein Repo)
Code im Repo (mehrere Dateien)	Teilweise	Falsches Werkzeug	Beste Wahl
API-JSON-Response	Falsches Werkzeug (False Positives bei Schlüsselreihenfolge)	Beste Wahl	Falsches Werkzeug
YAML-/TOML-Konfiguration	Teilweise (False Positives bei Schlüsselreihenfolge)	Beste Wahl (nach Konvertierung)	Teilweise
CSV zeilenweise	Teilweise	Falsches Werkzeug	Falsches Werkzeug
Log / Heredoc	Beste Wahl	Falsches Werkzeug	Falsches Werkzeug
Binärdatei	Falsches Werkzeug	Falsches Werkzeug	git diff --binary

6.2 Wann Text Diff das falsche Werkzeug ist

Drei klassische Fehler.

JSON mit umsortierten Schlüsseln. {"a":1,"b":2} und {"b":2,"a":1} sind dasselbe JSON-Dokument. Ein Text Diff meldet jede Zeile als verändert, weil sie tatsächlich unterschiedlich sind. Greifen Sie zum JSON vergleichen; er weiß, dass JSON-Schlüssel ungeordnet sind.

Reformatierte YAML-Konfigurationen. Ändern Sie einen Wert, schicken Sie die Datei durch einen Formatter, und Einrückung, Schlüsselreihenfolge und Quoting verschieben sich alle. Text Diff meldet eine komplette Neufassung. Konvertieren Sie beide Dateien zuerst nach JSON und vergleichen Sie dann mit JSON Diff.

Mehrdatei-Refactors mit Umbenennungen. Git verfolgt Umbenennungen, Text Diff nicht. Wenn Sie zwei Bäume vergleichen, indem Sie Dateien zu einem einzigen Blob konkatenieren, erscheint jeder dateiübergreifende Umzug als entfernt + hinzugefügt. Greifen Sie stattdessen zu git diff (oder git diff --find-renames=80%).

6.3 Wann Text Diff genau richtig ist

Prosa. Code-Snippets, von überall kopiert. Vertrags-Redlines. Log-Ausschnitte. Übersetzungsreviews, bei denen natürlichsprachliche Sätze einander gegenübergestellt werden. .env-Dateien, in denen die Reihenfolge zählt, weil Shells sie von oben nach unten lesen. Alles, wo die Zeilen selbst Bedeutung tragen.

Für die Tiefenanalyse beim Filtern von JSON-Diff-Rauschen (Timestamps, Request-IDs, automatisch generierte UUIDs) lesen Sie Timestamps und IDs in JSON Diff ignorieren.

7. Sechs Praxisfälle (mit Copy-and-paste-Eingaben)

7.1 Code-Review-Snippet: Funktionsumbenennung

Sie reviewen einen PR. Der Autor hat id zu userId umbenannt und eine Guard Clause ergänzt. Beide Versionen einfügen:

// 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;
}

Der Diff zeigt drei geänderte Zeilen plus eine hinzugefügte Zeile. Das Inline-Wort-Highlight markiert jedes id → userId-Token; die neue Guard Clause erscheint mit grünem Hintergrund. Ignore-Optionen sind aus. Probieren Sie es in Text Diff aus und kopieren Sie die Unified-Ausgabe direkt in einen Review-Kommentar.

7.2 Vertrags- oder Policy-Redline: eine eingefügte Klausel

Fünfzig Absätze Vertrag, eine eingefügte Klausel. Die gestrige Version links einfügen, die heutige 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.

Der Diff rendert neunundvierzig unveränderte Zeilen und eine hinzugefügte (+2a. Termination notice must be in writing.). Exportieren Sie den Unified Diff als revisionssichere Spur für die juristische Prüfung.

7.3 Log-Zeitachsen-Untersuchung

Sie vermuten eine Latenzregression. Greifen Sie sich einen Ausschnitt aus den Access-Logs vor und während des Vorfalls:

GET /api/users 200 14ms
POST /api/orders 201 88ms
GET /api/orders/42 200 21ms

GET /api/users 200 14ms
POST /api/orders 201 4200ms
GET /api/orders/42 500 21ms

Das Inline-Highlight zeigt 88 → 4200 (50-fache Latenz) und 200 → 500 (ein Order-Detail-Endpoint hat angefangen zu scheitern). Für tiefergehende Log-Arbeit (Felder extrahieren, nach Endpoint gruppieren, Perzentile berechnen) koppeln Sie das Diff mit dem jq-Spickzettel, falls Ihre Logs JSON sind.

7.4 Übersetzungsreview: Platzhalter erhalten

Sie haben eine neue Übersetzungsagentur engagiert und möchten verifizieren, dass die neue Copy strukturell mit der alten übereinstimmt. Alte Übersetzung links, neue rechts einfügen. Aktivieren Sie Trailing Spaces / Tabs ignorieren, weil Übersetzer:innen regelmäßig ein verirrtes Leerzeichen am Stringende hinterlassen.

Der Diff bestätigt, dass jedes {username}, jedes {count} und jedes %s an Ort und Stelle bleibt; nur die natürlichsprachlichen Texte ändern sich. Ein fehlender Platzhalter erscheint im Inline-Diff als entferntes Token, gefangen, bevor er live geht. Wenn Sie Platzhalter-Formate selbst vergleichen müssen, deckt der Regex-Spickzettel \{\w+\} und Konsorten ab. Probieren Sie es in Text Diff.

7.5 Konfigurations- oder .env-Audit: Produktion vs Staging

Vergleichen Sie zwei .env-Dateien. Aktivieren Sie Leerzeilen ignorieren, damit eine Absatz-Gruppierung Abschnitte nicht aus dem Tritt bringt. Der Diff zeigt Ihnen, welche Schlüssel sich im Wert unterscheiden, welche in einer Umgebung existieren und in der anderen nicht und wo Kommentare auseinandergedriftet sind. Fünf Minuten, die Ihnen die „Bei Staging geht’s, bei Produktion nicht”-Debug-Session ersparen.

7.6 Prosa- oder Manuskriptrevision

Ihre Lektorin schickt einen Entwurf zurück. Original links, redigierte Fassung rechts einfügen. Der Inline-Wort-Diff zeigt Ihnen genau, welche Sätze neu geschrieben, welche unangetastet blieben und welche Absätze eingefügt wurden. Akzeptieren oder verwerfen Sie Änderungen einzeln, ohne Track-Changes-Funktion, ohne Word-Datei, ohne proprietäres Format.

8. Häufige Stolperfallen und wie Sie sie als Symptome lesen

Das Verhalten des Algorithmus erklärt die meisten Schmerzen der Anwender. Fünf häufige Klagen und was sie tatsächlich bedeuten.

Stolperfalle 1: „Jede Zeile ist rot nach einer Windows-zu-Unix-Kopie.” Symptom: jede Zeile im Diff wird als geändert markiert, obwohl der Inhalt identisch aussieht. Ursache: angehängte \r-Zeichen aus CRLF-Zeilenumbrüchen. Lösung: „Trailing Spaces / Tabs ignorieren” aktivieren. Der Diff fällt auf die tatsächlichen Änderungen zurück.

Stolperfalle 2: „Ich habe JSON eingefügt, und 100 % der Zeilen sind verschieden.” Symptom: zwei JSON-Objekte, die äquivalent sein sollten, erscheinen vollständig geändert. Ursache: Schlüssel-Umsortierung. Text Diff behandelt Zeilenreihenfolge als signifikant, JSON nicht. Lösung: bei JSON-Eingaben JSON vergleichen verwenden.

Stolperfalle 3: „Reformatieren von Tabs ↔ Spaces hat den Diff zerlegt.” Symptom: 87 Modifikationen, allesamt Einrückung. Ursache: Ihr Formatter hat das führende Whitespace jeder Zeile geändert. Lösung: „Sämtliche Whitespaces ignorieren” kollabiert das Rauschen und holt die echten semantischen Änderungen ans Licht.

Stolperfalle 4: „Diff sagt identisch, cmp widerspricht.” Symptom: der Diff meldet keine Unterschiede, ein Byte-Vergleich aber schon. Ursache: eine Ignore-Option aus der vorigen Sitzung ist noch aktiv und maskiert echte Änderungen. Lösung: das Ignore-Panel öffnen, jeden Schalter deaktivieren und neu diffen.

Stolperfalle 5: „Eine kurze Änderung erscheint als Entfernen + Hinzufügen.” Symptom: eine kleine Änderung erscheint als separat entfernte und separat hinzugefügte Zeile statt als Inline-Highlight. Ursache: der Anteil geänderter Tokens hat die Inline-Schwelle überschritten und der Renderer ist auf die Paardarstellung umgeschwenkt. Das ist Absicht, kein Bug. Wechseln Sie zur Unified-Ansicht, um das klassische -/+-Paar zu sehen, das Patch-Tools erwarten.

9. Datenschutz, Performance und wann die Kommandozeile dran ist

Jeder Vergleich in Text Diff läuft als JavaScript in Ihrem Browser. Kein Upload, keine temporäre Datei, kein Serverlog, keine Analytics auf den von Ihnen eingefügten Text. Sicher für proprietären Code, interne Verträge und private Logs: alles, was Sie nicht in einen fremden Server kippen würden.

Praktische Grenzen: rund 5000 Zeilen oder 1 MB pro Seite. Live-Diff schaltet sich oberhalb von 200 KB kombiniert ab und wechselt zu einem manuellen Diff-Button, damit das Tippen die Seite nicht blockiert. Über 5000 Zeilen wird die Eingabe abgeschnitten und eine Warnung erscheint. Die Limits existieren, weil das Diff auf dem Main Thread läuft (kein Web Worker); ein Worker-Handoff plus Serialisierung würde auf kleinen Eingaben mehr kosten als das Diff selbst.

Wenn Ihre Eingabe den Browser sprengt, wechseln Sie auf die Kommandozeile:

# Unified diff between two files
diff -u a.txt b.txt

# Same, but using git's diff engine (Patience, Histogram, color)
git diff --no-index a.txt b.txt
git diff --no-index --patience a.txt b.txt

# Streaming diff viewer for huge files (Rust, side-by-side, syntax-aware)
delta a.txt b.txt

Wechseln Sie zur Kommandozeile bei mehreren Megabyte Log, bei Binärdateien, bei Multi-File-Repository-Diffs, immer wenn Sie syntaxbewusste Färbung wie delta brauchen, oder überall dort, wo Sie die Diff-Ausgabe in ein anderes Werkzeug pipen wollen.

10. Unicode, CJK und RTL: Hinweise zum internationalen Text Diff

Der Tokenizer splittet an Unicode-Wortgrenzen mit drei Kategorien: Wortfolgen (\p{L} Buchstaben und \p{N} Ziffern), Nicht-Wort-Interpunktion und Whitespace. Jede Kategorie erzeugt eigene Tokens, sodass hello, world! zu hello, ,, , world, ! wird, also fünf Tokens.

Bei CJK-Inhalten (Chinesisch, Japanisch, Koreanisch) ist jedes Ideogramm beziehungsweise jedes Kana ein eigenes Token. Ändern Sie ein Zeichen in einem chinesischen Satz, und nur dieses Zeichen trägt das Inline-Highlight, der Rest der Zeile bleibt gedimmt. Die Absatzstruktur bleibt zeilenbasiert; eine Satzumformulierung, die einen Zeilenumbruch einfügt, erscheint also als Zeilen-Edit, nicht als Token-Edit.

Bei RTL-Sprachen (Arabisch, Hebräisch) verwendet das Diff logische CSS-Richtungen (ms-, me- statt ml-, mr-). In RTL-Locales klappen Gutter und Zeilenspalten natürlicherweise; innerhalb jeder Diff-Zelle folgt die Textrichtung dem Inhalt, sodass arabische Strings rechts-nach-links rendern, während die +- und --Markierungen an der Start-Gutter ausgerichtet bleiben.

Die Normalisierung der Zeilenumbrüche erkennt \r\n (Windows), \n (Unix) und nacktes \r (klassisches Mac OS bis Version 9). Alle drei werden als getrennte Zeilen gesplittet, sodass eine zwischen Plattformen konvertierte Datei nicht zu einer einzigen Megazeile zusammenfällt.

11. FAQ

Wie funktioniert ein Online-Text-Diff?

Ein Text Diff splittet beide Eingaben in Zeilen, fährt einen LCS-Algorithmus (Longest Common Subsequence), typischerweise Myers O((N+M)D), um die kleinste Menge an Einfügungen und Löschungen zu finden, und hebt dann hinzugefügte (grün), entfernte (rot) und unveränderte (grau) Zeilen hervor. Ein zweites Token-LCS markiert die geänderten Wörter innerhalb jeder modifizierten Zeile. Text Diff führt den gesamten Vergleich lokal in Ihrem Browser aus.

Worin unterscheiden sich Text Diff und JSON Diff?

Text Diff vergleicht Zeile für Zeile, ideal für Prosa, Code, Logs und Verträge. JSON vergleichen versteht das JSON-Datenmodell: Schlüsselreihenfolge ist irrelevant, Typen sind streng (1 ≠ "1"), Arrays können per Schlüssel abgeglichen werden. Fügen Sie JSON in einen Text Diff ein, und Schlüssel-Umsortierungen oder Whitespace tauchen als Änderungen auf, die JSON Diff ignoriert. Text Diff für unstrukturierten Inhalt, JSON Diff für API-Responses und Konfigurationen.

Warum zeigt der Diff ganze Zeilen als geändert, wenn ich nur ein Wort editiert habe?

Tut er nicht. Die Zeile wird hervorgehoben, weil sich etwas darin geändert hat, aber innerhalb der Hervorhebung tragen nur die geänderten Tokens den hellen Hintergrund (grün für hinzugefügt, rot durchgestrichen für entfernt). Das ist der Inline-Worttausch-Diff: Der Zeilenkontext bleibt lesbar, während Ihr Auge auf der genauen Änderung landet. Wenn zu viel einer Zeile geändert wurde, fällt der Diff auf ein separates Entfernen-plus-Hinzufügen-Paar zurück, damit die Struktur sauber bleibt.

Wie ignoriere ich Whitespace, Groß-/Kleinschreibung oder Leerzeilen im Diff?

Schalten Sie das Ignore-Optionen-Panel um. „Groß-/Kleinschreibung ignorieren” macht A und a gleich. „Sämtliche Whitespaces ignorieren” kollabiert jedes Leerzeichen, jeden Tab und jeden Zeilenumbruch (äquivalent zu git diff -w). „Trailing Spaces und Tabs ignorieren” spiegelt git diff -b und stellt CRLF-Rauschen still. „Leerzeilen ignorieren” verwirft leere Zeilen, damit Absatzumformatierung den Diff nicht aus dem Tritt bringt. Jede Option ist unabhängig und überdauert die Sitzung.

Was ist das Unified-Diff-Format?

Der Unified Diff ist das Textformat ---/+++/@@ -L,C +L,C @@, eingeführt von GNU diff Ende der 1980er Jahre und verwendet von git, GitHub, GitLab und dem Unix-patch-Befehl. Jeder Hunk zeigt drei Kontextzeilen rund um die Änderung, mit - für entfernt und + für hinzugefügt. Kopieren Sie die Unified-Ausgabe in einen PR-Kommentar, fügen Sie sie in git apply ein oder fahren Sie patch -p1 < diff.patch; sie wendet sich sauber an.

Myers vs Patience: welcher Diff-Algorithmus ist besser fürs Code Review?

Myers ist der Standard in git diff und GNU diff: schnell und mathematisch minimal, aber er richtet manchmal unverwandte Leerzeilen oder schließende Klammern aus und produziert Diffs, die „komisch lesen”. Patience (Bram Cohen, 2005) verankert sich an Zeilen, die in jeder Eingabe genau einmal vorkommen, und rekursiert zwischen Ankern, sodass Funktionsgrenzen erhalten bleiben. Verwenden Sie git diff --patience (oder --histogram für ähnliche Ergebnisse, etwas schneller) beim Review von Refactors.

Wird der Text, den ich einfüge, an einen Server gesendet?

Nein. Jeder Vergleich in Text Diff läuft lokal als JavaScript in Ihrem Browser. Ihr Text wird niemals hochgeladen, geloggt, auf Disk gespeichert oder an Dritte gesendet. Nur Ihre UI-Präferenzen (Ansichtsmodus und Ignore-Schalter) werden in localStorage gespeichert, damit die Seite sie beim nächsten Besuch wiedererkennt; der Text niemals. Prüfen Sie es in den DevTools → Network: null Requests, wenn Sie auf Diff klicken.

Wie groß dürfen die beiden Eingaben sein?

Die praktische Grenze liegt bei rund 5000 Zeilen oder 1 MB pro Seite. Live-Diff deaktiviert sich oberhalb von 200 KB kombiniert und wechselt zu einem manuellen Diff-Button. Über 5000 Zeilen wird die Eingabe mit einer Warnung abgeschnitten. Für Dateien im Megabyte-Bereich wechseln Sie zu diff -u a.txt b.txt, git diff --no-index a.txt b.txt oder delta. Diese Werkzeuge streamen und bewältigen Gigabytes.