Plak versie A links, versie B rechts, en zie precies wat er is veranderd. Geen git clone, geen IDE, geen aanmelding. Draait volledig in je browser.
Een gratis tool in de browser om twee versies van code te vergelijken zonder Git, GitHub of je IDE te openen. Plak de oude versie links, de nieuwe rechts, en de verschillen worden teken voor teken gemarkeerd. De tekst verlaat nooit je machine, wat van belang is wanneer het fragment uit een private repo of een niet-gemergde branch komt.
Het is gebouwd voor het moment dat een collega twee versies van een functie in Slack dropt en vraagt "wat is er veranderd?". Een lokale checkout opzetten voor een diff van 12 regels is overkill. Net als de GitHub PR-view openen als je nog geen PR hebt. Twee tekstpanelen, één diff, klaar in vijftien seconden.
Dit is geen vervanging voor git diff op een echte working tree. Hunks stagen, patches toepassen of blame draaien kan niet. Wat wel kan, is het deel dat je het vaakst nodig hebt: twee willekeurige tekstblokken nemen en de bewerkingen ertussen tonen. Onder de motorkap gebruikt de diff dezelfde engine als onze compare-text-tool, ingericht voor code review.
De diff loopt teken voor teken, daarna groepeert een semantische opschoonpas de wijzigingen weer in leesbare blokken, zodat de markering op een hernoemde identifier valt en niet op elke afzonderlijke letter erin. Invoegingen in het rechterpaneel zijn groen; verwijderingen in het linkerpaneel rood. De twee panelen scrollen gekoppeld: vind je een wijziging op regel 80 aan één kant, springt de andere kant met je mee.
Waarom op tekenniveau in plaats van op regelniveau? Omdat voor korte fragmenten de zuivere regelweergave te grof is. Een variabele hernoemen van id naar userId is één identifierwijziging; een diff per regel toont de hele regel als verwijderd plus een hele nieuwe regel als ingevoegd, technisch waar maar de echte bewerking wordt zo lastiger te zien. De tekenmodus met semantische opschoning markeert het hernoemde token en laat de rest van de regel met rust. Bij lange bestanden draait de balans, en daarom is de klassieke regelgebaseerde diff wat Git standaard gebruikt. Beide hebben een plek. Deze tool geeft je de fragmentvriendelijke weergave.
Wat de tool bewust niet doet: het kent geen syntax. Het parseert geen JavaScript, Python of Java. Een geherformatteerd blok met dezelfde semantiek wordt nog steeds als diff getoond, want voor een tekstvergelijker is het andere tekst. Wil je formaatbewuste diffing voor gestructureerde payloads, dan doet onze pagina compare-json dat voor JSON, compare-yaml voor YAML en compare-xml voor XML- en POM-bestanden. Voor pure broncode is een tekstdiff plus je eigen ogen meestal sneller dan een syntaxbewuste tool configureren voor een eenmalig fragment.
Twee tekstpanelen, één diff. Geen login, geen upload, geen patchformaat om te parsen.
Kopieer de oude versie van de functie, het bestand of het fragment uit je editor, terminal of waar het ook staat. Ctrl+C en plak in het linkerpaneel. Als je uit git show <commit> trekt, kopieer dan de body van het bestand in plaats van de patch-header, zodat de diff alleen echte codewijzigingen markeert.
Hetzelfde met de nieuwe versie. Heeft een collega het in Slack, Teams of mail geplakt, kopieer dan rechtstreeks vanaf daar. Witruimte en inspringing blijven behouden bij plakken, wat van belang is voor talen waar inspringing betekenisvol is, zoals Python en YAML. Tab versus spaties verschijnt als verschil als de twee fragmenten niet overeenkomen.
Verwijderingen verschijnen als rode doorhalingen links; invoegingen als groen rechts. De wijzigingstellers in elke header zeggen hoeveel afzonderlijke bewerkingen zijn gedetecteerd. Lees de markeringen, focus eerst op logica-wijzigingen (control flow, condities, foutafhandeling) en behandel pure hernoemingen of opmaakwijzigingen als lagere prioriteit in de review.
Iemand dropt twee codeblokken in de chat en vraagt welke goed is. Repo clonen, branch wisselen en je IDE openen voor een fragment van 20 regels is verspilde moeite. Plak beide in de diff-tool en je hebt een antwoord voor het volgende bericht binnenkomt. Dit is verreweg de meest voorkomende reden om een online diff te gebruiken.
CI-pipelines, Dockerfiles, package.json en GitHub Actions workflow-YAML drijven constant. Een teamgenoot bewerkt .github/workflows/ci.yml op een branch, de build breekt, en je wilt zien wat er is veranderd zonder zijn branch uit te checken. Plak de main-versie naast de stuk-branch-versie en de fout-step duikt meestal binnen seconden op. Voor workflow-bestanden specifiek gaat onze YAML-diff-pagina netjes om met inspring-randgevallen.
Product managers, designers en account managers willen soms weten wat een codewijziging doet zonder een Git-interface te lezen. De GitHub PR-view veronderstelt vertrouwdheid met diff-syntax, bestandstructuren en review-comments. Voor en na in een schone twee-paneel-weergave plakken en samen door de markeringen lopen is veel vriendelijker. Ook handig in incident-postmortems wanneer het publiek mensen buiten engineering bevat.
Je hebt de output van git show abc123 en git show def456 voor een bestand over twee commits, misschien uit een CI-log of een remote sandbox waar je niet makkelijk git-commando's kunt uitvoeren. Strip de patch-headers, plak de twee bestandsinhouden en diff. Werkt goed bij debuggen op een server, het lezen van een build-artefact of het reviewen van een security-advisory die bestandsinhoud uit twee specifieke commits citeert.
Een leverancier stuurt een voorbeeldintegratie in een PDF. Een toezichthouder mailt een fragment beleidscode. Een consultant plakt een gepatchte versie van je script bij. Niets daarvan komt als clone-bare repo. Kopieer de tekst uit de PDF of mail, plak hem naast je huidige versie en je hebt binnen een minuut een bruikbaar review-oppervlak. Verwacht wat opmaakruis bij PDF-copy-paste; regelafbrekingen en aanhalingstekens zijn de gebruikelijke schuldigen.
De gevallen waarin een platte-tekstdiff niet overeenkomt met wat Git, je IDE of je code-reviewtool zou laten zien. Het is de moeite waard om door te scannen voor je productiecode plakt en je zorgen maakt om een vals positief.
| Topic | What this tool does |
|---|---|
| Regeleinden (CRLF vs LF) | CRLF in Windows-stijl en LF in Unix-stijl zijn verschillende bytes. Een bestand geplakt uit een Windows-editor en een uit een Linux-container verschijnen als volledige bestandsdiff als de regeleinden verschillen, zelfs met identieke zichtbare tekst. Git normaliseert dat met core.autocrlf; deze tool niet. |
| Trailing whitespace | Spaties of tabs aan het einde van een regel verschijnen als verschil. Gits core.whitespace kan bij commit waarschuwen of automatisch corrigeren; hier is wat je plakt wat je vergelijkt. Zit het ruisniveau van je code review vol met trailing-whitespace-edits, strip ze dan in je editor voor je gaat diffen. |
| Binaire bestanden | Deze tool is alleen voor tekst. De inhoud van een binair bestand plakken (een PNG, een gecompileerde JAR, een sqlite-DB) levert onzin op of doet de tab vastlopen. Voor binaire diff toont Git "Binary files differ" in plaats van een patch; voor de echte inhoud heb je formaatspecifieke tooling nodig. |
| .gitattributes text vs binary-markering | Een .gitattributes in een repo kan Gits text-vs-binary-detectie per bestandspatroon overschrijven. Die instelling reist niet mee met copy-paste. Vermoed je dat een bestand in twee checkouts anders behandeld wordt, dan is dat bestand de plek om naar te kijken; deze tool diff't het sowieso als platte tekst. |
| Diff per teken vs per regel | Deze pagina gebruikt diff op tekenniveau met semantische opschoning. Git werkt standaard per regel, met optioneel git diff --word-diff voor woordniveau. Tekenniveau is het beste voor korte fragmenten waar één token veranderde; regelniveau is het beste voor lange bestanden waar veel regels in bulk veranderden. |
| git diff --word-diff | De --word-diff-modus van Git markeert woordniveauwijzigingen binnen een regel, dichter bij wat deze tool voor fragmenten doet. Het outputformaat verschilt (terminalvriendelijke markup vs side-by-side panelen), maar de bedoeling overlapt. Leef je in de terminal, dan is --word-diff het lokale equivalent. |
| Drempels voor grote bestanden | Browser-gebaseerde diffs zijn responsief tot enkele duizenden regels per kant. Daarboven wordt semantische opschoning traag en wordt het gerenderde DOM zwaar. Voor enorme bestanden draai je git diff lokaal en pijp je naar een pager, of breek je de vergelijking op in kleinere secties. |
| Encoding (alleen UTF-8) | De diff gaat uit van UTF-8-input, wat in 2026 vrijwel alle broncode dekt. Bestanden opgeslagen als UTF-16, Windows-1252 of Shift-JIS kunnen bij plakken als mojibake verschijnen, afhankelijk van je browser. Lijkt een fragment door elkaar gehusseld, sla dan het bronbestand opnieuw op als UTF-8 voor je kopieert. |
Lokale git diff vergelijkt twee refs (commits, branches, working tree) in een echte repository. Het kent je index, je worktree en je history. Deze online tool doet niets daarvan. Het vergelijkt twee willekeurige tekstblokken die je plakt. Gebruik git diff voor echt review-werk op een uitgechecte repo. Gebruik dit wanneer je twee fragmenten hebt en geen handige manier om ze in een working tree te zetten, of wanneer je een side-by-side weergave wilt zonder van context te wisselen.
Niet precies. GitHub en GitLab gebruiken een regelgebaseerde unified diff met bestandscontext, hunk-headers en samenvattingen per bestand. Deze tool gebruikt diff op tekenniveau met semantische opschoning, beter voor korte fragmenten en slechter voor hele bestanden met veel wijzigingen. Voor een echte pull request-review ga je naar de GitHub PR-view. Voor een snelle fragmentvergelijking buiten de PR is dit sneller en hoef je niet naar de juiste repo te navigeren.
Nee. Dit is een platte-tekstdiff. Het parseert de taal niet, dus het kan niet zien dat een hernoemde variabele dezelfde identifier op 12 plekken is, en het kan geherformatteerde witruimte niet negeren zoals een syntaxbewuste diff zou doen. Voor de meeste fragment-reviews is dat prima, want je leest de markeringen met je eigen brein. Heb je echte semantische diffing voor code nodig, dan is je IDE (VS Code, IntelliJ) of een tree-sitter-gebaseerde diff het juiste gereedschap. Deze pagina optimaliseert voor snelheid, niet voor diep parsen.
Het klassieke Unix-commando diff -u produceert een patch in unified-formaat (hetzelfde formaat dat Git intern gebruikt). Het is regelgebaseerd en ontworpen om machinale leesbaar te zijn, zodat je de patch elders kunt toepassen. Deze tool is mensvriendelijk leesbaar. Hij toont twee side-by-side panelen met inline-markering in plaats van één kolom met plus- en minregels. Hij produceert geen patch-bestand dat je met git apply of patch -p1 kunt toepassen. Moet je een patch genereren, gebruik dan de command line. Wil je een diff lezen, dan is dit vriendelijker.
Ja, op zijn eigen voorwaarden. CRLF (Windows) en LF (Unix) regeleinden verschijnen als verschil als de twee geplakte fragmenten niet overeenkomen, want het zijn technisch andere bytes. Trailing whitespace ook. Dat is consistent met hoe Git bestanden behandelt als core.autocrlf uit staat. Geef je alleen om logica-wijzigingen en niet om witruimte, trim dan elk paneel voor het plakken. We bieden momenteel geen "witruimte negeren"-toggle, maar het staat op de roadmap; git diff -w is het lokale equivalent.
Praktisch wel. De diff draait in je browser, dus zeer grote inputs (een hele vendored library of een gegenereerd bestand van 50.000 regels) vertragen de pagina of doen de tab vastlopen, afhankelijk van hoeveel geheugen je browser heeft. Voor typisch code-reviewwerk (functies, bestanden, build-scripts, configs tot enkele duizenden regels per kant) is de diff praktisch direct klaar. Moet je hele repositories vergelijken, dan is een echte Git-tool of een mappenvergelijker het juiste antwoord; deze pagina is gebouwd voor fragmenten en losse bestanden.
Je code verlaat nooit je browser. De diff, de markering en de rendering draaien allemaal op je machine. We uploaden de tekst niet, loggen hem niet en geven hem niet door aan een derde partij. Dat is met name belangrijk voor review van eigen code: een nog niet uitgebrachte feature, een security-patch of een fragment uit een private repo in een clouddienst plakken kan op zichzelf al in strijd zijn met het databeleid van je werkgever. De claim verifiëren is eenvoudig. Open de DevTools van je browser, ga naar het Network-tabblad, plak beide versies en kijk mee. Er zijn geen uitgaande requests bij het vergelijken. Hetzelfde privacymodel geldt voor onze andere tools, waaronder compare-text, compare-json en compare-yaml. Code review werkt het beste wanneer het review-oppervlak te vertrouwen is.