Indsæt version A til venstre, version B til højre, og se præcis hvad der er ændret. Ingen git clone, ingen IDE, ingen tilmelding. Kører helt i din browser.
Et gratis værktøj i browseren til at diffe to kodeversioner uden at åbne Git, GitHub eller din IDE. Indsæt den gamle version til venstre, den nye til højre, og forskellene fremhæves tegn for tegn. Teksten forlader aldrig din maskine, hvilket har betydning, når snippet'en stammer fra et private repo eller en ikke-merget branch.
Det er bygget til det øjeblik, hvor en kollega smider to versioner af en funktion i Slack og spørger "hvad har ændret sig?". At sætte et lokalt checkout op for en 12-linjers diff er overdrevent. At åbne GitHub-PR-visningen, hvis PR'en endnu ikke findes, er det også. To tekstpaneler, én diff, klar på femten sekunder.
Dette erstatter ikke git diff på et rigtigt working tree. Det kan ikke stage hunks, anvende patches eller køre blame. Det det kan, er den del du oftest har brug for: tage to vilkårlige tekstklumper og vise redigeringerne mellem dem. Under motorhjelmen er diffen den samme motor, der driver vores compare-text-værktøj, her sat op til code review.
Diffen kører tegn for tegn, og dernæst grupperer en semantisk cleanup-pas ændringerne i læsbare klumper, så fremhævningen lander på en omdøbt identifier i stedet for hvert enkelt bogstav. Indsættelser i højre panel vises i grønt; sletninger i venstre panel i rødt. De to paneler scroll-låser sammen: finder du en ændring på linje 80 på den ene side, springer den anden side med dig.
Hvorfor tegnniveau frem for linjeniveau? Fordi linjevisning alene er for grov for korte snippets. At omdøbe en variabel fra id til userId er én identifier-ændring; en linjebaseret diff ville vise hele linjen som slettet plus en helt ny linje som indsat, teknisk korrekt, men den faktiske ændring bliver sværere at få øje på. Tegntilstand plus semantisk cleanup fremhæver det omdøbte token og lader resten af linjen være i fred. For lange filer vender afvejningen, og derfor bruger Git som standard klassisk linjebaseret diff. Begge har deres plads. Dette værktøj giver dig den snippet-venlige visning.
Hvad værktøjet bevidst ikke gør: det er ikke syntaks-bevidst. Det parser ikke JavaScript, Python eller Java. En reformateret blok med samme semantik vil stadig vises som diff, fordi det for en tekstsammenligner er anden tekst. Vil du have formatbevidst diffing for strukturerede payloads, gør vores compare-json-side det for JSON, compare-yaml for YAML og compare-xml for XML og POM-filer. For ren kildekode er tekstdiff plus dine egne øjne som regel hurtigere end at konfigurere et syntaksbevidst værktøj til en engangsopgave.
To tekstpaneler, én diff. Ingen login, ingen upload, intet patch-format at parse.
Kopiér den gamle version af funktionen, filen eller snippet'en fra din editor, terminal eller hvor den nu ligger. Ctrl+C og indsæt så i venstre panel. Trækker du fra git show <commit>, så kopiér filens krop snarere end patch-headeren, så diffen kun fremhæver reelle kodeændringer.
Det samme med den nye version. Har en kollega indsat den i Slack, Teams eller mail, så kopiér direkte derfra. Whitespace og indrykning bevares ved indsætning, hvilket har betydning i sprog, hvor indrykning er meningsbærende, som Python og YAML. Tab vs mellemrum vil vise sig som forskel, hvis de to snippets ikke stemmer overens.
Sletninger vises som røde overstregninger til venstre; indsættelser som grønt til højre. Ændringstællerne i hver header siger, hvor mange separate redigeringer der er fundet. Læs fremhævningerne igennem, fokusér først på logikændringer (kontrolflow, betingelser, fejlhåndtering), og behandl rene omdøbninger eller formateringsændringer som lavere prioritet i gennemgangen.
Nogen smider to kodeblokke i chatten og spørger, hvilken der er rigtig. At klone repoet, skifte branch og åbne IDE'en for en 20-linjers snippet er spildt indsats. Indsæt begge i diff-værktøjet, og du har svaret, før næste besked lander. Det er den hyppigste grund til, at folk griber efter en online diff.
CI-pipelines, Dockerfiles, package.json og YAML for GitHub Actions-workflows driver hele tiden. En holdkammerat redigerer .github/workflows/ci.yml på en branch, builden går i stykker, og du vil se hvad der er ændret uden at checke deres branch ud. Indsæt main-versionen ved siden af den ødelagte branch-version, og det skyldige step dukker som regel op på sekunder. Specifikt for workflow-filer håndterer vores YAML-diff-side kantsager omkring indrykning renere.
Produktchefer, designere og account managers har nogle gange brug for at vide, hvad en kodeændring gør, uden at skulle læse en Git-grænseflade. GitHubs PR-visning forudsætter fortrolighed med diff-syntaks, filtræer og review-kommentarer. At indsætte før-og-efter i en ren topanelvisning og gå fremhævningerne igennem sammen er meget mere venligt. Også nyttigt i incident-postmortems, hvor publikum inkluderer folk uden for engineering.
Du har git show abc123-output og git show def456-output for en fil over to commits, måske fra en CI-log eller en remote sandbox, hvor du ikke nemt kan køre git-kommandoer. Skræl patch-headerne af, indsæt de to filindhold og diff. Virker godt, når du debugger på en server, læser et build-artefakt eller gennemgår en sikkerhedsadvisory, der citerer filindhold fra to specifikke commits.
En leverandør sender en eksempelintegration i en PDF. En tilsynsmyndighed mailer en snippet med policy-kode. En konsulent vedhæfter en patchet version af dit script. Intet af det kommer som et klonbart repo. Kopiér teksten fra PDF'en eller mailen, indsæt den ved siden af din nuværende version, og du har en brugbar review-overflade på under et minut. Forvent en smule formateringsstøj fra PDF-kopiering; linjeskift og citationstegn er de sædvanlige skurke.
De tilfælde, hvor en ren tekstdiff er uenig med, hvad Git, din IDE eller dit code review-værktøj ville vise. Værd at skimme, før du indsætter produktionskode og bekymrer dig om en falsk positiv.
| Topic | What this tool does |
|---|---|
| Linjeafslutninger (CRLF vs LF) | Windows-stil CRLF og Unix-stil LF er forskellige bytes. En fil indsat fra en Windows-editor og en fil indsat fra en Linux-container vil vise sig som diff på hele filen, hvis linjeafslutningerne ikke stemmer, selv med identisk synlig tekst. Git normaliserer det med core.autocrlf; dette værktøj gør ikke. |
| Afsluttende whitespace | Mellemrum eller tabs i slutningen af en linje vil vise sig som forskel. Gits core.whitespace kan advare eller auto-rette ved commit; her er det, du indsætter, det du sammenligner. Er støjniveauet i dit code review fyldt med trailing-whitespace-ændringer, så fjern dem i editoren før du differ. |
| Binære filer | Dette værktøj er kun til tekst. At indsætte indholdet af en binær fil (en PNG, en kompileret JAR, en sqlite-DB) vil producere volapyk eller låse fanen. Til binær diff viser Git "Binary files differ" snarere end en patch; du har brug for formatspecifikt værktøj til det egentlige indhold. |
| .gitattributes-markering text vs binary | Et repos .gitattributes kan tilsidesætte Gits text-vs-binary-detektion per filmønster. Den indstilling rejser ikke med kopiér-indsæt. Mistænker du, at en fil behandles forskelligt mellem to checkouts, er den fil stedet at kigge; dette værktøj vil diffe den som ren tekst alligevel. |
| Tegn- vs linjediff | Denne side bruger tegnniveau-diff med semantisk cleanup. Git går som standard på linjeniveau, valgfrit med git diff --word-diff for ordniveau. Tegnniveau er bedst til korte snippets, hvor et enkelt token er ændret; linjeniveau er bedst til lange filer, hvor mange linjer er ændret samlet. |
| git diff --word-diff | Gits --word-diff-tilstand fremhæver ændringer på ordniveau inde i en linje, tættere på det dette værktøj gør for snippets. Outputformatet er anderledes (terminalvenligt markup vs side om side-paneler), men intentionen overlapper. Lever du i terminalen, er --word-diff den lokale pendant. |
| Tærskler for store filer | Browser-baserede diffs er responsive op til nogle få tusind linjer per side. Derudover bliver semantisk cleanup langsom, og den renderede DOM tung. For enorme filer kør git diff lokalt og rør outputtet til en pager, eller del sammenligningen op i mindre afsnit. |
| Encoding (kun UTF-8) | Diffen antager UTF-8-input, hvilket dækker næsten al kildekode i 2026. Filer gemt som UTF-16, Windows-1252 eller Shift-JIS kan vise sig som mojibake ved indsætning afhængig af din browser. Ser en snippet rodet ud, så gem kildefilen igen som UTF-8, før du kopierer. |
Lokalt git diff sammenligner to refs (commits, branches, working tree) inde i et rigtigt repository. Det kender dit index, dit worktree og din historik. Dette online-værktøj gør intet af det. Det sammenligner to vilkårlige tekstblokke, du indsætter. Brug git diff til reelt review-arbejde på et udchecket repo. Brug dette, når du har to snippets og ingen bekvem måde at få dem ind i et working tree på, eller når du vil have en sammenligning side om side uden kontekstskift.
Ikke helt. GitHub og GitLab bruger en linjebaseret unified diff med filkontekst, hunk-headers og opsummeringer per fil. Dette værktøj bruger tegnniveau-diff med semantisk cleanup, bedre til korte snippets og dårligere til hele filer med mange ændringer. Til et reelt pull request-review gå til GitHubs PR-visning. Til en hurtig snippet-sammenligning uden for PR'en er dette hurtigere og kræver ikke, at du navigerer til det rigtige repo.
Nej. Dette er en ren tekstdiff. Det parser ikke sproget, så det kan ikke fortælle, at en omdøbt variabel er den samme identifier 12 steder, og det kan ikke ignorere reformateret whitespace, sådan som en syntaksbevidst diff ville. For det meste snippet-review er det fint, fordi du læser fremhævningerne med din egen hjerne. Har du brug for ægte semantisk diffing af kode, er din IDE (VS Code, IntelliJ) eller en tree-sitter-baseret diff det rigtige værktøj. Denne side optimerer for hastighed, ikke dyb parsning.
Den klassiske Unix-kommando diff -u producerer en patch i unified-format (samme format som Git bruger internt). Den er linjebaseret og designet til at være maskinlæsbar, så du kan anvende patchen et andet sted. Dette værktøj er menneskelæsbart. Det viser to side om side-paneler med inline-fremhævning i stedet for en enkelt kolonne med plus- og minus-linjer. Det producerer ikke en patch-fil, du kan anvende med git apply eller patch -p1. Skal du generere en patch, brug kommandolinjen. Skal du læse en diff, er dette venligere.
Ja, men på sine egne præmisser. CRLF (Windows) og LF (Unix) linjeafslutninger vil vise sig som forskel, hvis de to indsatte snippets ikke stemmer overens, fordi det teknisk set er forskellige bytes. Afsluttende whitespace ligeså. Det er konsistent med, hvordan Git behandler filer, når core.autocrlf er slået fra. Vil du kun se logikændringer og ikke whitespace, så trim hvert panel før du indsætter. Vi tilbyder ikke aktuelt en "ignorer whitespace"-toggle, men den er på roadmappen; git diff -w er den lokale pendant.
I praksis ja. Diffen kører i din browser, så meget store input (et helt vendoreret bibliotek eller en genereret fil på 50.000 linjer) vil sløve siden eller låse fanen, alt efter hvor meget hukommelse din browser har. Til typisk kodereview-arbejde (funktioner, filer, build-scripts, configs på op til nogle få tusind linjer per side) bliver diffen reelt færdig med det samme. Skal du sammenligne hele repositories, er et rigtigt Git-værktøj eller en mappesammenligner det rigtige svar; denne side er bygget til snippets og enkeltfiler.
Din kode forlader aldrig din browser. Diffen, fremhævningen og renderingen kører alt sammen på din maskine. Vi uploader ikke teksten, logger den ikke og sender den ikke videre til nogen tredjepartstjeneste. Det betyder noget specifikt ved review af proprietær kode: at indsætte en ikke-udgivet feature, en sikkerhedspatch eller en snippet fra et private repo i en cloud-tjeneste kan i sig selv overtræde din arbejdsgivers datapolitik. At verificere påstanden er ligetil. Åbn browserens DevTools, skift til Network-fanen, indsæt begge versioner og hold øje. Der er ingen udgående requests, når du sammenligner. Den samme privatlivsmodel gælder i vores andre værktøjer, herunder compare-text, compare-json og compare-yaml. Code review virker bedst, når review-overfladen er til at stole på.