Lim inn versjon A til venstre, versjon B til høyre, og se nøyaktig hva som er endret. Ingen git clone, ingen IDE, ingen registrering. Alt kjører i nettleseren.
Et gratis verktøy i nettleseren for å diffe to kodeversjoner uten å åpne Git, GitHub eller IDE-en din. Lim den gamle versjonen til venstre, den nye til høyre, og forskjellene fremheves tegn for tegn. Teksten forlater aldri maskinen din, noe som har betydning når snippet'en er fra et private repo eller en branch som ikke er merget.
Det er bygget for øyeblikket der en kollega slenger to versjoner av en funksjon i Slack og spør "hva har endret seg?". Å spinne opp en lokal checkout for en 12-linjers diff er overkill. Å åpne GitHub PR-visningen før PR-en finnes likeså. To tekstpaneler, én diff, ferdig på femten sekunder.
Dette erstatter ikke git diff på et reelt working tree. Det kan ikke stage hunks, applisere patches eller kjøre blame. Det det kan, er den delen du oftest trenger: ta to vilkårlige tekstblokker og vise endringene mellom dem. Under panseret bruker diffen samme motor som driver verktøyet vårt compare-text, her satt opp for code review.
Diffen kjører tegn for tegn, og deretter samler en semantisk cleanup-passering endringene i lesbare biter slik at fremhevingen lander på en omdøpt identifier i stedet for hver enkelt bokstav i den. Innlegg i høyre panel rendres i grønt; sletting i venstre panel rendres i rødt. De to panelene scroller synkront: finner du en endring på linje 80 på den ene siden, hopper den andre med deg.
Hvorfor tegnnivå i stedet for linjenivå? Fordi for korte snippets blir ren linjevisning for grov. Å døpe om en variabel fra id til userId er én identifier-endring; en linjebasert diff ville vise hele linjen som slettet pluss en helt ny linje som innsatt, teknisk korrekt, men selve endringen blir vanskeligere å se. Tegnmodus pluss semantisk cleanup fremhever det omdøpte tokenet og lar resten av linjen være i fred. For lange filer snur avveiningen, og det er derfor Git bruker klassisk linjebasert diff som standard. Begge har sin plass. Dette verktøyet gir deg snippet-vennlig visning.
Hva verktøyet bevisst ikke gjør: det er ikke syntaks-bevisst. Det parser ikke JavaScript, Python eller Java. En reformatert blokk med samme semantikk vil fortsatt vises som diff, fordi det for en tekstsammenligner er annen tekst. Vil du ha formatbevisst diffing for strukturerte payloads, gjør siden vår compare-json det for JSON, compare-yaml for YAML og compare-xml for XML og POM-filer. For ren kildekode er tekstdiff pluss dine egne øyne som regel raskere enn å sette opp et syntaksbevisst verktøy for en engangs-snippet.
To tekstpaneler, én diff. Ingen innlogging, ingen opplasting, intet patch-format å parse.
Kopier den gamle versjonen av funksjonen, fila eller snippet'en fra editoren, terminalen eller hvor enn den ligger. Ctrl+C, og lim deretter inn i venstre panel. Henter du fra git show <commit>, kopier filkroppen i stedet for patch-headeren, slik at diffen bare fremhever reelle kodeendringer.
Det samme med den nye versjonen. Har en kollega limt den i Slack, Teams eller mail, kopier direkte derfra. Whitespace og innrykk bevares ved innliming, noe som har betydning for språk der innrykk er meningsbærende, som Python og YAML. Tab vs mellomrom dukker opp som forskjell hvis de to snippetene ikke stemmer overens.
Sletting vises som rød overstreking til venstre; innlegg som grønt til høyre. Endringstellerne i hver header forteller hvor mange separate redigeringer som er funnet. Les gjennom fremhevingene, fokuser først på logikkendringer (kontrollflyt, betingelser, feilhåndtering), og behandle rene navnebytter eller formateringsendringer som lavere prioritet i gjennomgangen.
Noen slipper to kodeblokker i chatten og spør hvilken som er riktig. Å klone repoet, bytte branch og åpne IDE-en for en 20-linjers snippet er bortkastet innsats. Lim begge inn i diff-verktøyet, og du har svaret før neste melding kommer. Dette er den vanligste grunnen til at folk griper en online diff.
CI-pipelines, Dockerfiles, package.json og YAML for GitHub Actions-workflow drifter konstant. En lagkamerat redigerer .github/workflows/ci.yml på en branch, builden ryker, og du vil se hva som er endret uten å sjekke ut branch-en deres. Lim main-versjonen ved siden av den ødelagte branch-versjonen, og det skyldige steget dukker som regel opp på sekunder. For workflow-filer spesifikt håndterer vår YAML-diff-side kanttilfeller for innrykk renere.
Produktansvarlige, designere og account managers trenger noen ganger å vite hva en kodeendring gjør, uten å lese et Git-grensesnitt. GitHubs PR-visning antar fortrolighet med diff-syntaks, filtrær og review-kommentarer. Å lime inn før-og-etter i en ren topanelvisning og gå gjennom fremhevingene sammen er mye vennligere. Også nyttig i incident-postmortem når publikummet inkluderer folk utenfor engineering.
Du har git show abc123-output og git show def456-output for en fil over to commits, kanskje fra en CI-logg eller en remote sandbox der du ikke enkelt kan kjøre git-kommandoer. Skrell av patch-headerne, lim inn de to filinnholdene og diff. Funker bra når du feilsøker på en server, leser et build-artefakt eller går gjennom et sikkerhetsvarsel som siterer filinnhold fra to spesifikke commits.
En leverandør sender en eksempelintegrasjon i en PDF. En tilsynsmyndighet mailer en snippet med policy-kode. En konsulent legger ved en patchet versjon av skriptet ditt. Ingen av dem kommer som et klonbart repo. Kopier teksten ut av PDF-en eller mailen, lim den ved siden av din nåværende versjon, og du har en brukbar review-flate på under et minutt. Forvent litt formateringsstøy fra PDF-kopiering; linjeskift og hermetegn er de vanlige skurkene.
Tilfellene der en ren tekstdiff er uenig med det Git, IDE-en din eller code review-verktøyet ville vist. Verdt å skumme før du limer inn produksjonskode og bekymrer deg for en falsk positiv.
| Topic | What this tool does |
|---|---|
| Linjeavslutninger (CRLF vs LF) | Windows-stil CRLF og Unix-stil LF er ulike bytes. En fil limt inn fra en Windows-editor og en fil limt inn fra en Linux-container vil dukke opp som diff på hele fila hvis linjeavslutningene er forskjellige, selv med identisk synlig tekst. Git normaliserer det med core.autocrlf; dette verktøyet gjør ikke. |
| Avsluttende whitespace | Mellomrom eller tabs i slutten av en linje vil dukke opp som forskjell. Gits core.whitespace kan advare eller auto-fikse på commit; her er det du limer inn det du sammenligner. Er støygulvet i code review-en din fullt av trailing-whitespace-endringer, fjern dem i editoren før du differ. |
| Binærfiler | Dette verktøyet er bare for tekst. Å lime inn innholdet i en binærfil (en PNG, en kompilert JAR, en sqlite-DB) vil produsere tøv eller låse fanen. For binær diff viser Git "Binary files differ" i stedet for en patch; du trenger formatspesifikt verktøy for selve innholdet. |
| .gitattributes-merking text vs binary | Et repos .gitattributes kan overstyre Gits text-vs-binary-deteksjon per filmønster. Den innstillingen reiser ikke med kopier-lim. Mistenker du at en fil behandles ulikt mellom to checkouts, er den fila stedet å se; dette verktøyet vil diffe den som ren tekst uansett. |
| Tegn- vs linjediff | Denne siden bruker tegnnivå-diff med semantisk cleanup. Git går standard på linjenivå, valgfritt med git diff --word-diff for ordnivå. Tegnnivå er best for korte snippets der ett enkelt token er endret; linjenivå er best for lange filer der mange linjer er endret samlet. |
| git diff --word-diff | Gits --word-diff-modus fremhever endringer på ordnivå inne i en linje, nærmere det dette verktøyet gjør for snippets. Outputformatet er ulikt (terminalvennlig markup vs side-ved-side-paneler), men intensjonen overlapper. Lever du i terminalen, er --word-diff den lokale motparten. |
| Terskler for store filer | Nettleserbaserte diffs er responsive opp til noen tusen linjer per side. Forbi det blir semantisk cleanup tregt, og den rendrede DOM-en tung. For enorme filer kjør git diff lokalt og send til en pager, eller del sammenligningen i mindre seksjoner. |
| Encoding (kun UTF-8) | Diffen antar UTF-8-input, noe som dekker nesten all kildekode i 2026. Filer lagret som UTF-16, Windows-1252 eller Shift-JIS kan vises som mojibake ved innliming avhengig av nettleser. Ser en snippet rotete ut, lagre kildefila på nytt som UTF-8 før kopiering. |
Lokalt git diff sammenligner to refs (commits, branches, working tree) inne i et reelt repository. Det vet om indeksen din, worktreet ditt og historikken din. Dette online-verktøyet gjør ingen av delene. Det sammenligner to vilkårlige tekstblokker du limer inn. Bruk git diff til reelt review-arbeid på et utsjekket repo. Bruk dette når du har to snippets og ingen praktisk måte å lande dem i et working tree, eller når du vil ha en side-ved-side-visning uten kontekstbytte.
Ikke helt. GitHub og GitLab bruker en linjebasert unified diff med filkontekst, hunk-headers og oppsummeringer per fil. Dette verktøyet bruker tegnnivå-diff med semantisk cleanup, bedre for korte snippets og dårligere for hele filer med mange endringer. For et reelt pull request-review gå til GitHubs PR-visning. For en rask snippetsammenligning utenfor PR-en er dette raskere og krever ikke at du navigerer til riktig repo.
Nei. Dette er en ren tekstdiff. Det parser ikke språket, så det kan ikke se at en omdøpt variabel er samme identifier 12 steder, og det kan ikke ignorere reformatert whitespace slik en syntaksbevisst diff ville. For mesteparten av snippet-review går det fint, fordi du leser fremhevingene med din egen hjerne. Trenger du ekte semantisk diffing for kode, er IDE-en din (VS Code, IntelliJ) eller en tree-sitter-basert diff det riktige verktøyet. Denne siden optimaliserer for fart, ikke dyp parsing.
Den klassiske Unix-kommandoen diff -u produserer en patch i unified-format (samme format som Git bruker internt). Den er linjebasert og designet for å være maskinlesbar slik at du kan applisere patchen et annet sted. Dette verktøyet er menneskelesbart. Det viser to side-ved-side-paneler med inline-fremheving i stedet for en enkelt kolonne med pluss- og minus-linjer. Det produserer ikke en patch-fil du kan applisere med git apply eller patch -p1. Skal du generere en patch, bruk kommandolinjen. Skal du lese en diff, er dette vennligere.
Ja, men på sine egne premisser. CRLF (Windows) og LF (Unix) linjeavslutninger vil dukke opp som forskjell hvis de to innlimte snippetene ikke stemmer overens, fordi det teknisk sett er ulike bytes. Avsluttende whitespace likeså. Det er konsistent med hvordan Git behandler filer når core.autocrlf er av. Vil du bare se logikkendringer og ikke whitespace, trim hvert panel før innliming. Vi tilbyr foreløpig ingen "ignorer whitespace"-toggle, men den ligger på roadmappen; git diff -w er den lokale motparten.
I praksis ja. Diffen kjører i nettleseren, så veldig store input (et helt vendoret bibliotek eller en generert fil på 50 000 linjer) vil senke siden eller låse fanen avhengig av hvor mye minne nettleseren har. For typisk kodereview-arbeid (funksjoner, filer, build-skript, configer på opp til noen tusen linjer per side) blir diffen i praksis ferdig umiddelbart. Skal du sammenligne hele repositories, er et reelt Git-verktøy eller en mappesammenligner riktig svar; denne siden er bygget for snippets og enkeltfiler.
Koden din forlater aldri nettleseren. Diffen, fremhevingen og renderingen kjører alt på maskinen din. Vi laster ikke opp teksten, logger den ikke, og videresender den ikke til noen tredjeparts tjeneste. Det betyr noe spesifikt ved review av proprietær kode: å lime en uutgitt feature, en sikkerhetspatch eller en snippet fra et private repo inn i en skytjeneste kan i seg selv bryte arbeidsgiverens datapolicy. Å verifisere påstanden er enkelt. Åpne nettleserens DevTools, bytt til Network-fanen, lim inn begge versjonene og se på. Det er ingen utgående requests når du sammenligner. Samme personvernmodell gjelder i de andre verktøyene våre, inkludert compare-text, compare-json og compare-yaml. Kodegjennomgang virker best når review-flaten er til å stole på.