Die beiden Texte werden in Bausteine zerlegt — Zeilen, Wörter oder einzelne Zeichen — und verglichen, indem die längste Folge gesucht wird, die in beiden in derselben Reihenfolge vorkommt. Alles außerhalb dieser Folge ist eine Hinzufügung oder eine Entfernung. So vergleichen Versionsverwaltungen Dateien, und genau das macht das Ergebnis lesbar: Übereinstimmende Blöcke bleiben stehen, statt dass nach einer eingefügten Zeile jede folgende als geändert gemeldet wird.
Übereinstimmende Abschnitte am Anfang und Ende beider Texte werden erkannt und beiseitegelegt, bevor die Vergleichstabelle entsteht, was bei echten Dokumenten den größten Teil der Arbeit erspart, da Änderungen meist auf einen Teil der Datei beschränkt sind. Groß- und Kleinschreibung oder umgebenden Leerraum zu ignorieren ändert, was als Übereinstimmung zählt; angezeigt wird Ihnen stets das Original, ein ignorierter Unterschied wird also nicht umgeschrieben, sondern nur nicht mehr hervorgehoben.
Den Vergleich lesen
-
Eine geänderte Zeile ist eine Entfernung plus eine Hinzufügung:
Auf Zeilenebene gibt es kein Konzept einer geänderten Zeile — die alte geht, die neue kommt. Wechseln Sie auf Wortebene, um zu sehen, was sich darin tatsächlich geändert hat.
-
Die Zahlen zählen Bausteine, keine Änderungen:
Auf Wortebene kann ein umformulierter Satz ein Dutzend Hinzufügungen melden. Vergleichen Sie die Zahlen zwischen zwei Durchläufen, statt sie als Anzahl der Änderungen zu lesen.
-
Die Granularität ist die wichtigste Einstellung:
Zeilen für Code und strukturierten Text, Wörter für Fließtext, Zeichen für kurze Zeichenketten, in denen Sie eine einzelne falsche Ziffer suchen.
-
Der Vergleich auf Zeichenebene ist der teure:
Der Aufwand wächst mit dem Produkt der beiden Längen, weshalb ein langes Dokument Zeichen für Zeichen verglichen spürbar länger dauert als dasselbe Dokument zeilenweise.
An edited line is a removal and an addition
The comparison works line by line. When a line changes, it is not reported as "modified" — it appears as the old line removed and the new line added, adjacent to each other.
That is how nearly every diff works, and it explains the counts. Change one word in one line and the summary says one removal and one addition, not one change. A file where you altered a comma on every line will report as entirely rewritten.
The [msm_tool slug="text-diff"] works this way, and knowing it stops the numbers being alarming.
Whitespace counts
Two lines that look identical differ if one has a trailing space, or if one uses tabs where the other uses spaces. The comparison is exact.
This is the most common source of "these are the same, why is it showing a difference". Trailing whitespace is invisible in most editors, and it is the usual culprit. If a diff shows changes you cannot see, that is what to look for first.
Line endings are the other invisible difference
Windows ends lines with a carriage return and a line feed; Unix and macOS use a line feed alone. A file that has travelled between the two can differ on every single line while looking identical.
If an entire document reports as changed and you know it has not been, check the line endings before checking anything else.
Reordering is not detected as reordering
Move a paragraph from the top of a document to the bottom, and the diff reports it as removed from one place and added in another. It has no concept of a block having moved.
That is correct behaviour for a line-based comparison and it makes large reorganisations hard to read. For those, comparing section by section is usually more informative than comparing the whole document.
What it is genuinely good at
- Verifying a small edit. Confirming that a change to a config file, a contract or a translation touched only what you intended.
- Comparing two versions someone sent you without version control — two Word exports, two email drafts, two vendor quotes.
- Checking a copy-paste survived. Whether the text in the CMS matches the text that was approved.
- Finding an unintended change. The diff you run because something broke and you want to know what moved.
What to use instead, when
For code under version control, your version control system's diff is better — it knows the history, handles renames, and can show word-level changes within a line.
For prose where you want to see which words changed rather than which lines, a word-level comparison is far more readable. A line-based diff of a rewritten paragraph tells you the paragraph changed, which you knew.
For structured data — JSON, YAML, configuration — a structural comparison is better again, because it ignores formatting and key order and reports what actually differs.
Nothing is uploaded
Both texts are compared in your browser, which is worth knowing when the documents are a contract, an unreleased announcement, or anything else you would rather not paste into a service.