Diff-Checker & Smart-Formatter – Text, Code, JSON und Markdown lokal vergleichen

Du bekommst einen überarbeiteten Vertragsentwurf, eine von KI umformulierte Markdown-Dokumentation oder zwei einzeilige JSON-Antworten aus einer Schnittstelle und willst in Sekunden wissen, welches Detail sich tatsächlich verändert hat. Klassische Online-Vergleichsseiten schicken solche sensiblen Inhalte jedoch häufig an fremde Server oder markieren bei umsortiertem JSON den gesamten Block pauschal als geändert.

Ein lokaler Browser-Diff zerlegt beide Eingaben im Arbeitsspeicher über den Myers-Algorithmus in Zeilen- und Wort-Token und berechnet die kleinste Folge aus Einfügungen und Löschungen. Bringt ein vorgeschalteter Formatter unstrukturierte Eingaben zuerst in eine einheitliche Form – etwa durch alphabetisch sortierte JSON-Schlüssel –, bleiben nur noch echte Inhaltsänderungen übrig. Bei dateiübergreifenden Code-Umbauten oder mehrstelligen Megabyte-Logs stößt ein Browser-Vergleich dagegen an seine Grenzen.

Warum reine Zeilenvergleiche täuschen und wie der Myers-Algorithmus arbeitet

Hinter fast jedem modernen Diff-Werkzeug – einschließlich git diff – steckt der 1986 von Eugene W. Myers veröffentlichte Algorithmus für das Kürzestes Edit-Skript (SES) (Minimale Folge von Lösch- und Einfügeoperationen, die Text A in Text B überführt; das Gegenstück dazu ist die längste gemeinsame Teilfolge (Longest Common Subsequence).). Seine Laufzeit liegt bei O((N + M) · D), wobei N und M die Anzahl der Zeilen oder Wörter beider Texte beschreiben und D für die Anzahl der tatsächlichen Unterschiede steht. Sind sich zwei Dokumente ähnlich (D ist klein), läuft der Vergleich im Browser selbst bei tausenden Zeilen in wenigen Millisekunden durch.

In der Praxis scheitert ein Vergleich selten am Algorithmus, sondern an Schein-Unterschieden in der Eingabe:

1. Einzeiliges oder umsortiertes JSON: Laut RFC 8259 sind JSON-Objekte ungeordnete Schlüssel-Wert-Sammlungen ({"a":1,"b":2} bedeutet fachlich exakt dasselbe wie {"b":2,"a":1}). Ein reiner Textvergleich meldet hier fälschlich 100 Prozent Abweichung, solange die Schlüssel vorab nicht in eine Kanonische Normalform (Eindeutige Standarddarstellung einer Datenstruktur – etwa feste Einrückung und alphabetisch sortierte Objektschlüssel –, sodass semantisch gleiche Daten identischen Text ergeben.) gebracht werden.
2. Lange Fließtext-Absätze: In Verträgen, E-Mails oder Dokumentationen ist ein ganzer Absatz oft eine einzige lange Zeile ohne manuellen Zeilenumbruch. Markiert ein Werkzeug nur die komplette Zeile rot und grün, übersieht das Auge leicht ein einzelnes eingefügtes Wort wie „nicht“ oder eine geänderte Kündigungsfrist. Erst ein zweistufiger Durchlauf – zuerst Zeilen-Diff, innerhalb geänderter Zeilenpaare anschließend Wort-Diff – hebt die exakte Stelle hervor.
3. Gemischte Zeilenenden (CRLF vs. LF): Kopierst du einen Text aus einem Windows-Editor und den zweiten aus einer Linux-Konsole oder einem Chatfenster, weicht jedes Zeilenende unsichtbar um das Steuerzeichen \r ab.

1import { diffLines } from "diff";
2
3// Rekursive kanonische Sortierung verhindert Fehlalarme bei JSON-Vergleichen
4export function canonicalizeJson(rawJson: string): string {
5  const sortDeep = (val: unknown): unknown => {
6    if (Array.isArray(val)) {
7      // Array-Reihenfolge bleibt bewusst erhalten, da sie fachlich relevant sein kann!
8      return val.map(sortDeep);
9    }
10    if (val !== null && typeof val === "object") {
11      return Object.fromEntries(
12        Object.entries(val as Record<string, unknown>)
13          .sort(([keyA], [keyB]) => keyA.localeCompare(keyB))
14          .map(([key, nested]) => [key, sortDeep(nested)])
15      );
16    }
17    return val;
18  };
19
20  const parsed: unknown = JSON.parse(rawJson);
21  return JSON.stringify(sortDeep(parsed), null, 2);
22}
23
24export function diffJsonPayloads(beforeRaw: string, afterRaw: string) {
25  const normalizedBefore = canonicalizeJson(beforeRaw);
26  const normalizedAfter = canonicalizeJson(afterRaw);
27  return diffLines(normalizedBefore, normalizedAfter);
28}

Beachte im Code ein wichtiges Detail: Objektschlüssel dürfen alphabetisch sortiert werden, Arrays ([...]) dagegen nicht automatisch, weil [10, 20] und [20, 10] in vielen Schnittstellen eine fachlich bedeutsame Reihenfolge (z. B. Prioritäten oder Zeitreihen) abbilden.

Welches Vergleichsverfahren passt zu welchem Dokumenttyp?

Prüfpunkte beim Prüfen von Code, JSON und Verträgen

• Datenschutz vor dem Einfügen klären: Enthält der Text personenbezogene Daten, API-Schlüssel oder Vertragsentwürfe, darf kein Netzwerk-Request stattfinden (prüfbar im Browser-Netzwerk-Tab oder im Flugmodus der installierten PWA).
• Einrückungssensitive Formate beachten: Prüfst du YAML, Python oder Markdown-Codeblöcke, lasse die Option Leerzeichen ignorieren ausgeschaltet.
• Zahlen und Negationen einzeln gegenlesen: Achte in den farbig hinterlegten Wort-Markierungen gezielt auf kleine Wörter („nicht“, „höchstens“, „exklusive“) sowie geänderte Einheiten (Tage vs. Werktage, ms vs. s).

Quellen und nächste Schritte

• Eugene W. Myers (1986) – An O(ND) Difference Algorithm and Its Variations (Algorithmica, Vol. 1, S. 251–266): xmailserver.org/diff2.pdf
• IETF RFC 8259 – The JavaScript Object Notation (JSON) Data Interchange Format (Objekt-Ungeordnetheit in Sektion 4): datatracker.ietf.org/doc/html/rfc8259
• GitHub Flavored Markdown Spec (GFM) – Tabellen, Task-Listen und Fenced Code Blocks: github.github.com/gfm
• jsdiff (Referenzimplementierung für Zeilen- & Wort-Diffs in JavaScript) – github.com/kpdecker/jsdiff
• Weiterführend im Digital Garden: Lies Git Workflows für saubere Commit- und Review-Strategien in Teams oder MDX – Markdown trifft React-Komponenten, wenn aus statischem Markdown interaktive Oberflächen werden sollen.