Version A links einfügen, Version B rechts, und sehen, was sich geändert hat. Kein git clone, keine IDE, keine Anmeldung. Läuft komplett im Browser.
Ein kostenloses Browser-Tool, um zwei Code-Versionen ohne Git, GitHub oder IDE zu vergleichen. Fügen Sie die alte Version links ein, die neue rechts, und die Unterschiede werden Zeichen für Zeichen markiert. Der Text verlässt nie Ihren Rechner. Das ist wichtig, wenn das Snippet aus einem privaten Repo oder einem ungemergten Branch stammt.
Gebaut für den Moment, in dem ein Kollege zwei Versionen einer Funktion in Slack postet und fragt: "Was hat sich geändert?". Einen lokalen Checkout für ein 12-Zeilen-Diff hochzuziehen, ist Overkill. Genauso die GitHub-PR-Ansicht zu öffnen, wenn es noch keine PR gibt. Zwei Textfenster, ein Diff, in fünfzehn Sekunden erledigt.
Das ist kein Ersatz für git diff auf einem echten Working Tree. Hunks lassen sich nicht stagen, Patches nicht anwenden, blame nicht ausführen. Was es kann, ist der Teil, den man am häufigsten braucht: zwei beliebige Textblöcke nehmen und die Änderungen zeigen. Darunter nutzt das Diff dieselbe Engine wie unser compare-text-Tool, hier auf Code Review zugeschnitten.
Das Diff läuft Zeichen für Zeichen, dann fasst ein semantischer Cleanup-Pass die Änderungen zu lesbaren Blöcken zusammen, sodass die Markierung auf einem umbenannten Bezeichner sitzt und nicht auf jedem einzelnen Buchstaben darin. Insertions im rechten Panel werden grün gerendert; Deletions im linken Panel rot. Beide Panels scrollen synchron: finden Sie auf einer Seite eine Änderung in Zeile 80, springt die andere Seite mit.
Warum auf Zeichen- statt auf Zeilenebene? Weil bei kurzen Snippets die reine Zeilenansicht zu grob ist. Eine Variable von id in userId umzubenennen ist eine einzige Bezeichnerschaft; ein Zeilen-Diff zeigt die ganze Zeile als gelöscht plus eine ganze neue Zeile als eingefügt. Technisch korrekt, aber die eigentliche Änderung ist schwerer zu erkennen. Zeichenmodus mit semantischem Cleanup markiert das umbenannte Token und lässt den Rest der Zeile in Ruhe. Bei langen Dateien dreht sich der Trade-off; deshalb nutzt Git standardmäßig das klassische zeilenbasierte Diff. Beides hat seinen Platz. Dieses Tool gibt Ihnen die Snippet-freundliche Ansicht.
Was das Tool bewusst nicht macht: Es kennt keine Syntax. Es parst nicht JavaScript, Python oder Java. Ein neu formatierter Block mit gleicher Semantik wird trotzdem als Diff angezeigt, weil es für einen Textvergleicher unterschiedlicher Text ist. Wenn Sie format-bewusstes Diffing für strukturierte Daten brauchen, macht unsere Seite compare-json das für JSON, compare-yaml für YAML und compare-xml für XML und POM-Dateien. Für reinen Quellcode ist das Text-Diff plus Ihre eigenen Augen meist schneller, als ein syntaxbewusstes Tool für eine einmalige Sache zu konfigurieren.
Zwei Textfenster, ein Diff. Kein Login, kein Upload, kein Patch-Format zum Parsen.
Kopieren Sie die alte Version der Funktion, Datei oder des Snippets aus Ihrem Editor, Terminal oder wo immer sie liegt. Strg+C, dann ins linke Panel einfügen. Wenn Sie aus git show <commit> ziehen, kopieren Sie den Datei-Body und nicht den Patch-Header, damit das Diff nur echte Code-Änderungen markiert.
Dasselbe mit der neuen Version. Hat ein Kollege sie in Slack, Teams oder per Mail gepostet, kopieren Sie direkt von dort. Whitespace und Einrückung bleiben beim Einfügen erhalten, was bei Sprachen mit signifikanter Einrückung wie Python und YAML zählt. Tab vs. Spaces erscheint als Unterschied, wenn die beiden Snippets nicht übereinstimmen.
Deletions erscheinen als rote Durchstreichungen links; Insertions als Grün rechts. Die Änderungszähler in jedem Header sagen Ihnen, wie viele eigenständige Edits erkannt wurden. Lesen Sie die Markierungen durch, schauen Sie zuerst auf Logikänderungen (Kontrollfluss, Bedingungen, Fehlerbehandlung) und behandeln Sie reine Umbenennungen oder Formatierungsänderungen im Review-Pass als niedrigere Priorität.
Jemand wirft zwei Codeblöcke in den Chat und fragt, welcher korrekt ist. Repo klonen, Branch wechseln und IDE für ein 20-Zeilen-Snippet öffnen ist verschwendete Arbeit. Beides ins Diff-Tool einfügen und Sie haben die Antwort, bevor die nächste Nachricht eintrifft. Das ist der häufigste Grund, warum Leute zu einem Online-Diff greifen.
CI-Pipelines, Dockerfiles, package.json und YAML für GitHub Actions Workflows driften ständig auseinander. Ein Teamkollege ändert .github/workflows/ci.yml in einem Branch, der Build bricht, und Sie wollen sehen, was sich geändert hat, ohne den Branch auszuchecken. Fügen Sie die main-Version neben die kaputte Branch-Version ein, und der schuldige Step taucht meist in Sekunden auf. Speziell für Workflow-Dateien geht unsere YAML-Diff-Seite mit Einrückungsfällen sauberer um.
Product Manager, Designer und Account Manager müssen manchmal verstehen, was eine Code-Änderung tut, ohne ein Git-Interface lesen zu können. Die GitHub-PR-Ansicht setzt Vertrautheit mit Diff-Syntax, Dateibäumen und Review-Kommentaren voraus. Vorher-Nachher in eine saubere Zwei-Panel-Ansicht zu kleben und die Markierungen gemeinsam durchzugehen, ist deutlich freundlicher. Auch nützlich in Incident-Postmortems, wenn das Publikum Leute außerhalb der Engineering-Org einschließt.
Sie haben den Output von git show abc123 und git show def456 für eine Datei über zwei Commits hinweg, vielleicht aus einem CI-Log oder einer Remote-Sandbox, in der Sie nicht ohne Weiteres git-Kommandos ausführen können. Patch-Header entfernen, die beiden Datei-Inhalte einfügen und diffen. Funktioniert gut beim Debuggen auf einem Server, beim Lesen eines Build-Artefakts oder beim Review eines Security-Advisorys, das Datei-Inhalte aus zwei bestimmten Commits zitiert.
Ein Anbieter schickt eine Beispiel-Integration als PDF. Eine Aufsichtsbehörde mailt ein Snippet Policy-Code. Ein Berater hängt eine gepatchte Version Ihres Skripts an. Nichts davon kommt als klonbares Repo. Text aus PDF oder Mail kopieren, neben Ihre aktuelle Version einfügen, und Sie haben in unter einer Minute eine brauchbare Review-Oberfläche. Erwarten Sie Format-Rauschen beim Kopieren aus PDF; Zeilenumbrüche und Anführungszeichen sind die üblichen Verdächtigen.
Die Fälle, in denen ein Plain-Text-Diff sich von dem unterscheidet, was Git, Ihre IDE oder Ihr Code-Review-Tool zeigen würde. Lohnt sich, einmal durchzulesen, bevor man Produktionscode einfügt und sich Sorgen über einen False Positive macht.
| Topic | What this tool does |
|---|---|
| Zeilenenden (CRLF vs. LF) | CRLF im Windows-Stil und LF im Unix-Stil sind unterschiedliche Bytes. Eine Datei aus einem Windows-Editor und eine Datei aus einem Linux-Container erscheinen als komplettes Datei-Diff, wenn die Zeilenenden nicht übereinstimmen, selbst bei identischem sichtbaren Text. Git normalisiert das mit core.autocrlf; dieses Tool nicht. |
| Nachgestellter Whitespace | Leerzeichen oder Tabs am Zeilenende erscheinen als Unterschied. Gits core.whitespace kann beim Commit warnen oder automatisch korrigieren; hier ist das Eingefügte das Verglichene. Wenn die Geräuschkulisse Ihres Code-Reviews voll mit Trailing-Whitespace-Edits ist, entfernen Sie diese im Editor vor dem Diff. |
| Binärdateien | Dieses Tool ist nur für Text. Den Inhalt einer Binärdatei (PNG, kompiliertes JAR, sqlite-DB) einzufügen erzeugt Unsinn oder hängt den Tab. Für Binär-Diff zeigt Git "Binary files differ" statt eines Patches; für den eigentlichen Inhalt braucht es format-spezifisches Tooling. |
| .gitattributes-Markierung Text vs. Binary | Eine .gitattributes im Repo kann Gits Erkennung von Text vs. Binary pro Dateimuster überschreiben. Diese Einstellung wandert nicht mit Copy-Paste mit. Wenn Sie vermuten, dass eine Datei in zwei Checkouts unterschiedlich behandelt wird, ist genau diese Datei der Ort zum Schauen; dieses Tool wird sie ohnehin als Plain Text diffen. |
| Zeichen- vs. Zeilen-Diff | Diese Seite nutzt Diff auf Zeichenebene mit semantischem Cleanup. Git geht standardmäßig auf Zeilenebene, mit optionalem git diff --word-diff auf Wortebene. Zeichenebene ist am besten für kurze Snippets, in denen sich ein einzelnes Token geändert hat; Zeilenebene ist am besten für lange Dateien mit vielen Zeilenänderungen am Stück. |
| git diff --word-diff | Gits --word-diff-Modus markiert Änderungen auf Wortebene innerhalb einer Zeile, näher an dem, was dieses Tool für Snippets macht. Das Ausgabeformat ist anders (terminalfreundliches Markup vs. Side-by-Side-Panels), aber die Absicht überlappt sich. Wer im Terminal lebt, hat in --word-diff das lokale Pendant. |
| Schwellen für große Dateien | Browser-basierte Diffs sind reaktionsfähig bis zu wenigen tausend Zeilen pro Seite. Darüber hinaus wird semantisches Cleanup langsam und das gerenderte DOM schwer. Für sehr große Dateien führen Sie git diff lokal aus und leiten Sie es in einen Pager, oder zerlegen Sie den Vergleich in kleinere Abschnitte. |
| Encoding (nur UTF-8) | Das Diff geht von UTF-8-Eingabe aus, was 2026 fast den gesamten Quellcode abdeckt. Dateien, die als UTF-16, Windows-1252 oder Shift-JIS gespeichert sind, können beim Einfügen je nach Browser als Mojibake erscheinen. Wenn ein Snippet zerwürfelt aussieht, speichern Sie die Quelldatei vor dem Kopieren als UTF-8. |
Lokales git diff vergleicht zwei Refs (Commits, Branches, Working Tree) in einem echten Repository. Es kennt Ihren Index, Ihren Worktree und Ihre History. Dieses Online-Tool macht nichts davon. Es vergleicht zwei beliebige Textblöcke, die Sie einfügen. Nutzen Sie git diff für echtes Review auf einem ausgecheckten Repo. Nutzen Sie das hier, wenn Sie zwei Snippets haben und keinen bequemen Weg, sie in einem Working Tree zu landen, oder wenn Sie eine Side-by-Side-Ansicht ohne Kontextwechsel wollen.
Nicht ganz. GitHub und GitLab nutzen ein zeilenbasiertes Unified Diff mit Datei-Kontext, Hunk-Headern und Pro-Datei-Zusammenfassungen. Dieses Tool nutzt Diff auf Zeichenebene mit semantischem Cleanup, besser für kurze Snippets, schlechter für ganze Dateien mit vielen Änderungen. Für ein echtes Pull-Request-Review gehen Sie in die GitHub-PR-Ansicht. Für einen schnellen Snippet-Vergleich außerhalb der PR ist das hier schneller und verlangt nicht, ins richtige Repo zu navigieren.
Nein. Das ist ein Plain-Text-Diff. Es parst die Sprache nicht und kann daher nicht erkennen, dass eine umbenannte Variable an 12 Stellen derselbe Bezeichner ist, und es kann reformatierte Whitespaces nicht so ignorieren wie ein syntaxbewusstes Diff. Für die meisten Snippet-Reviews reicht das, weil Sie die Markierungen mit dem eigenen Kopf lesen. Wenn Sie echtes semantisches Diffing für Code brauchen, ist Ihre IDE (VS Code, IntelliJ) oder ein tree-sitter-basiertes Diff das richtige Werkzeug. Diese Seite optimiert auf Geschwindigkeit, nicht auf tiefes Parsing.
Das klassische Unix-Kommando diff -u erzeugt einen Patch im Unified-Format (dasselbe Format, das Git intern nutzt). Es ist zeilenbasiert und für Maschinenlesbarkeit gedacht, damit man den Patch anderswo anwenden kann. Dieses Tool ist menschenlesbar. Es zeigt zwei Side-by-Side-Panels mit Inline-Hervorhebung statt einer einzigen Spalte aus Plus- und Minus-Zeilen. Es erzeugt keine Patch-Datei, die Sie mit git apply oder patch -p1 anwenden können. Wenn Sie einen Patch erzeugen müssen, nehmen Sie die Kommandozeile. Wenn Sie ein Diff lesen wollen, ist das hier freundlicher.
Ja, aber nach eigener Logik. CRLF (Windows) und LF (Unix) erscheinen als Unterschied, wenn die beiden eingefügten Snippets nicht übereinstimmen, weil es technisch unterschiedliche Bytes sind. Trailing Whitespace ebenso. Das ist konsistent damit, wie Git Dateien behandelt, wenn core.autocrlf aus ist. Wenn Sie nur Logikänderungen sehen wollen und kein Whitespace, trimmen Sie jedes Panel vor dem Einfügen. Einen "Whitespace ignorieren"-Toggle bieten wir derzeit nicht, er steht aber auf der Roadmap; git diff -w ist das lokale Pendant.
Praktisch ja. Das Diff läuft im Browser, daher verlangsamen sehr große Eingaben (eine ganze vendored Library oder eine generierte Datei mit 50.000 Zeilen) die Seite oder hängen den Tab je nach verfügbarem Browser-Speicher. Für typische Code-Review-Arbeit (Funktionen, Dateien, Build-Skripte, Configs bis zu wenigen tausend Zeilen pro Seite) wird das Diff praktisch sofort fertig. Wenn Sie ganze Repositories vergleichen müssen, ist ein echtes Git-Tool oder ein Folder-Vergleich die richtige Antwort; diese Seite ist für Snippets und einzelne Dateien gebaut.
Ihr Code verlässt nie Ihren Browser. Diff, Hervorhebung und Rendering laufen alle auf Ihrem Rechner. Wir laden den Text nicht hoch, loggen ihn nicht und geben ihn an keinen Drittdienst weiter. Das zählt speziell beim Review von proprietärem Code: ein unveröffentlichtes Feature, einen Security-Patch oder ein Snippet aus einem privaten Repo in einen Cloud-Dienst zu kleben kann allein schon gegen die Datenschutzrichtlinien Ihres Arbeitgebers verstoßen. Die Aussage ist leicht zu prüfen. Öffnen Sie die DevTools des Browsers, wechseln Sie auf den Network-Tab, fügen Sie beide Versionen ein und schauen Sie zu. Beim Vergleichen gibt es keine ausgehenden Requests. Dasselbe Datenschutzmodell gilt in unseren anderen Tools, darunter compare-text, compare-json und compare-yaml. Code-Review funktioniert am besten, wenn die Review-Oberfläche vertrauenswürdig ist.