Klistra in version A till vänster, version B till höger, och se exakt vad som ändrats. Ingen git clone, ingen IDE, ingen registrering. Allt körs i webbläsaren.
Ett gratis verktyg i webbläsaren för att jämföra två kodversioner utan att öppna Git, GitHub eller IDE. Klistra in den gamla versionen till vänster, den nya till höger, och skillnaderna markeras tecken för tecken. Texten lämnar aldrig din maskin, vilket spelar roll när snippeten kommer från ett private repo eller en omergad branch.
Det är byggt för stunden då en kollega slänger två versioner av en funktion i Slack och frågar "vad har ändrats?". Att dra upp en lokal checkout för en 12-radig diff är överdrivet. Att öppna GitHub PR-vyn när det inte ens finns en PR likaså. Två textpaneler, en diff, klart på femton sekunder.
Det här ersätter inte git diff på ett riktigt working tree. Det kan inte staga hunks, applicera patches eller köra blame. Det det kan göra är den del du oftast behöver: ta två godtyckliga textblock och visa vad som ändrats mellan dem. Under huven använder diffen samma motor som driver vårt verktyg compare-text, här riggat för code review.
Diffen körs tecken för tecken, sedan grupperar en semantisk cleanup-omgång om förändringarna i läsbara klumpar så att markeringen landar på en omdöpt identifierare snarare än varje enskild bokstav. Tillägg i högra panelen ritas i grönt; borttagningar i vänstra panelen i rött. De två panelerna scrollar synkat: när du hittar en ändring på rad 80 på ena sidan hoppar den andra med dig.
Varför teckennivå istället för radnivå? För kortare snippets är ren radvy för grovkornig. Att döpa om en variabel från id till userId är en enda identifierarändring; en raddiff skulle visa hela raden som borttagen plus en helt ny rad inlagd, tekniskt sant men gör den faktiska redigeringen svårare att se. Teckenläge plus semantisk cleanup markerar den omdöpta token och lämnar resten av raden i fred. För långa filer vänder kompromissen, och därför använder Git som standard klassisk radbaserad diff. Båda har sin plats. Det här verktyget ger dig den snippetvänliga vyn.
Vad verktyget medvetet inte gör: det förstår inte syntax. Det parsar inte JavaScript, Python eller Java. Ett omformaterat block med samma semantik visas ändå som diff, eftersom det för en textjämförare är annan text. Vill du ha formatmedveten diffning för strukturerade payloads gör vår sida compare-json det för JSON, compare-yaml för YAML och compare-xml för XML och POM-filer. För ren källkod är textdiff plus dina egna ögon oftast snabbare än att konfigurera ett syntaxmedvetet verktyg för en engångssnippet.
Två textpaneler, en diff. Ingen inloggning, ingen uppladdning, inget patchformat att parsa.
Kopiera den gamla versionen av funktionen, filen eller snippeten från din editor, terminal eller varhelst den finns. Ctrl+C, klistra sedan in i vänstra panelen. Om du drar från git show <commit> ska du kopiera filens kropp och inte patch-headern, så att diffen bara markerar verkliga kodändringar.
Gör samma sak med den nya versionen. Har en kollega klistrat den i Slack, Teams eller mail kopierar du direkt därifrån. Whitespace och indentering bevaras vid inklistring, vilket är viktigt i språk där indentering är betydelsebärande som Python och YAML. Tab kontra spaces dyker upp som skillnad om de två snippets inte stämmer överens.
Borttagningar visas som röda överstrykningar till vänster; tillägg som grönt till höger. Förändringsräknarna i varje header säger hur många separata redigeringar som upptäckts. Läs igenom markeringarna, fokusera först på logikändringar (kontrollflöde, villkor, felhantering) och behandla rena namnbyten eller formateringsändringar som lägre prioritet i granskningen.
Någon släpper två kodblock i chatten och frågar vilken som är rätt. Att klona repot, byta branch och öppna IDE för en 20-radig snippet är bortkastad ansträngning. Klistra in båda i diff-verktyget och du har svaret innan nästa meddelande landar. Det här är det vanligaste skälet att gripa efter en online-diff.
CI-pipelines, Dockerfiles, package.json och YAML för GitHub Actions-workflow driver hela tiden. En lagkamrat redigerar .github/workflows/ci.yml på en branch, builden går sönder, och du vill se vad som ändrats utan att checka ut hens branch. Klistra in main-versionen bredvid den trasiga branch-versionen så dyker det skyldiga steget oftast upp på sekunder. För workflow-filer specifikt hanterar vår YAML-diff-sida kantfall för indentering renare.
Produktchefer, designers och account managers behöver ibland veta vad en kodändring gör utan att läsa ett Git-gränssnitt. GitHubs PR-vy förutsätter förtrogenhet med diff-syntax, filträd och granskningskommentarer. Att klistra in före och efter i en ren tvåpanelvy och gå igenom markeringarna tillsammans är mycket vänligare. Också användbart i incidentpostmortem när publiken inkluderar folk utanför engineering.
Du har git show abc123-utdata och git show def456-utdata för en fil över två commits, kanske från en CI-logg eller en remote sandbox där du inte enkelt kan köra git-kommandon. Skala bort patch-headers, klistra in de två filinnehållen och diffa. Funkar bra när du felsöker på en server, läser en build-artefakt eller granskar en säkerhetsadvisory som citerar filinnehåll från två specifika commits.
En leverantör skickar en exempelintegration i en PDF. En tillsynsmyndighet mailar en snippet med policykod. En konsult bifogar en patchad version av ditt skript. Inget av det kommer som ett klonbart repo. Kopiera texten ur PDF:en eller mailet, klistra in den bredvid din nuvarande version och du har en användbar granskningsyta på under en minut. Räkna med lite formateringsbrus från PDF-kopiering; radbrytningar och citattecken är de vanliga bovarna.
Fallen där en ren textdiff inte håller med om vad Git, din IDE eller ditt kodgranskningsverktyg skulle visa. Värt att skumma innan du klistrar in produktionskod och oroar dig för en falsk träff.
| Topic | What this tool does |
|---|---|
| Radslut (CRLF vs LF) | Windows-stil CRLF och Unix-stil LF är olika bytes. En fil inklistrad från en Windows-editor och en fil inklistrad från en Linux-container visas som filomfattande diff om radsluten skiljer sig, även med identisk synlig text. Git normaliserar det med core.autocrlf; det här verktyget gör det inte. |
| Avslutande whitespace | Mellanslag eller tabbar i slutet av en rad visas som skillnad. Gits core.whitespace kan varna eller autofixa vid commit; här är det du klistrar in det du jämför. Är bullernivån i din kodgranskning full av trailing-whitespace-edits, ta bort dem i editorn innan du diffar. |
| Binärfiler | Det här verktyget är bara för text. Att klistra in innehållet i en binärfil (en PNG, en kompilerad JAR, en sqlite-DB) producerar nonsens eller låser fliken. För binär diff visar Git "Binary files differ" snarare än en patch; du behöver formatspecifikt verktyg för det faktiska innehållet. |
| .gitattributes-markering text vs binary | En repos .gitattributes kan åsidosätta Gits text-vs-binary-detektion per filmönster. Den inställningen följer inte med en kopia-klistra. Misstänker du att en fil behandlas olika mellan två checkouts är just den filen platsen att titta på; det här verktyget kommer att diffa den som ren text oavsett. |
| Tecken- vs raddiff | Den här sidan använder teckendiff med semantisk cleanup. Git går som standard på radnivå, med valfritt git diff --word-diff för ordnivå. Tecken är bäst för korta snippets där en enda token ändrats; rad är bäst för långa filer där många rader ändrats i bulk. |
| git diff --word-diff | Gits --word-diff-läge markerar ändringar på ordnivå inuti en rad, närmare det det här verktyget gör för snippets. Utdataformatet skiljer sig (terminalvänlig markup vs sida-vid-sida-paneler), men avsikten överlappar. Lever du i terminalen är --word-diff den lokala motsvarigheten. |
| Tröskel för stora filer | Webbläsarbaserade diffar är responsiva upp till några tusen rader per sida. Bortom det blir semantisk cleanup långsam och den renderade DOM:en tung. För enorma filer kör git diff lokalt och pajpa till en pager, eller bryt jämförelsen i mindre sektioner. |
| Encoding (endast UTF-8) | Diffen antar UTF-8-indata, vilket täcker nästan all källkod 2026. Filer sparade som UTF-16, Windows-1252 eller Shift-JIS kan visas som mojibake vid inklistring beroende på din webbläsare. Ser en snippet hopblandad ut, spara om källfilen som UTF-8 innan du kopierar. |
Lokalt git diff jämför två refs (commits, branches, working tree) inuti ett riktigt repository. Det vet om ditt index, ditt worktree och din historik. Det här online-verktyget gör inget av det. Det jämför två godtyckliga textblock du klistrar in. Använd git diff för verkligt granskningsarbete på ett utcheckat repo. Använd det här när du har två snippets och inget bekvämt sätt att få in dem i ett working tree, eller när du vill ha en sida-vid-sida-vy utan att byta kontext.
Inte exakt. GitHub och GitLab använder en radbaserad unified diff med filkontext, hunk-headers och sammanfattningar per fil. Det här verktyget använder teckendiff med semantisk cleanup, bättre för korta snippets och sämre för hela filer med många ändringar. För en riktig pull request-granskning gå till GitHubs PR-vy. För en snabb snippetjämförelse utanför PR är det här snabbare och kräver inte att du navigerar till rätt repo.
Nej. Det här är en ren textdiff. Det parsar inte språket, så det kan inte se att en omdöpt variabel är samma identifierare på 12 ställen och kan inte ignorera omformaterad whitespace som en syntaxmedveten diff skulle. För det mesta av snippetgranskning är det okej, eftersom du läser markeringarna med din egen hjärna. Behöver du verklig semantisk diffning för kod är din IDE (VS Code, IntelliJ) eller en tree-sitter-baserad diff rätt verktyg. Den här sidan optimerar för fart, inte djup parsning.
Det klassiska Unix-kommandot diff -u producerar en patch i unified-format (samma format Git använder internt). Det är radbaserat och designat för att vara maskinläsbart så att du kan applicera patchen någon annanstans. Det här verktyget är människoläsbart. Det visar två sida-vid-sida-paneler med inline-markering snarare än en enda kolumn med plus- och minusrader. Det producerar inte en patch-fil du kan applicera med git apply eller patch -p1. Behöver du generera en patch, använd kommandoraden. Behöver du läsa en diff är det här vänligare.
Ja, men på sina egna villkor. CRLF (Windows) och LF (Unix) radslut visas som skillnad om de två inklistrade snippetsen inte stämmer överens, eftersom det tekniskt är olika bytes. Avslutande whitespace likaså. Det är konsekvent med hur Git behandlar filer när core.autocrlf är av. Bryr du dig bara om logikändringar och inte whitespace, trimma varje panel innan du klistrar in. Vi erbjuder för närvarande ingen "ignorera whitespace"-toggle, men den är på roadmappen; git diff -w är den lokala motsvarigheten.
I praktiken ja. Diffen körs i webbläsaren, så väldigt stora indata (ett helt vendorat bibliotek eller en genererad fil på 50 000 rader) kommer att sega ner sidan eller låsa fliken beroende på hur mycket minne webbläsaren har. För typisk kodgranskning (funktioner, filer, build-skript, configs upp till några tusen rader per sida) blir diffen klar i princip direkt. Behöver du jämföra hela repon är ett riktigt Git-verktyg eller ett mappjämförelseverktyg rätt svar; den här sidan är byggd för snippets och enstaka filer.
Din kod lämnar aldrig webbläsaren. Diffen, markeringen och renderingen körs alla på din maskin. Vi laddar inte upp texten, loggar den inte och skickar den inte vidare till någon tredjepartstjänst. Det spelar roll specifikt vid granskning av proprietär kod: att klistra in en orelease feature, en säkerhetspatch eller en snippet ur ett private repo i en molntjänst kan i sig bryta mot din arbetsgivares datapolicy. Att verifiera påståendet är enkelt. Öppna webbläsarens DevTools, byt till Network-fliken, klistra in båda versionerna och titta på. Det finns inga utgående requests när du jämför. Samma integritetsmodell gäller i våra andra verktyg, däribland compare-text, compare-json och compare-yaml. Kodgranskning fungerar bäst när granskningsytan går att lita på.