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.
Inte på det sätt du kanske väntar dig. Det här verktyget jämför två fullständiga versioner som du klistrar in, en per panel, och räknar ut ändringarna självt. Det tar inte en befintlig .patch eller git diff-utdata och visar den sida vid sida. Klistrar du in en unified diff i en panel jämför du bara den patch-texten med vad som finns i den andra panelen, vilket nästan aldrig är meningen. För att läsa en patch här, återskapa de två filversionerna (före och efter) och klistra in dem. Att tillämpa eller skapa en patch är fortfarande ett jobb för git apply eller patch -p1 på kommandoraden.
Ja. Diffen körs helt i din webbläsare; koden laddas aldrig upp, loggas eller skickas till någon server. Det är just därför den här finns i stället för en moln-diff-tjänst. Att klistra in en osläppt funktion, en säkerhetspatch eller en kunds privata fil i ett serverbaserat verktyg kan bryta mot din arbetsgivares datapolicy eller ett NDA. Här finns ingen sådan exponering. Vill du kontrollera det? Öppna DevTools, håll koll på Network-fliken medan du klistrar in båda sidorna, så ser du att inga utgående anrop görs.
Gratis, och det finns inget konto att skapa. Ingen provtimer, ingen platsgräns, ingen e-postspärr. Klistra in version A, klistra in version B, läs diffen, stäng fliken. Varje knapp fungerar vid första besöket utan inloggning. Det är ett verktyg för ett enda syfte, inte en freemium-tratt, så det finns ingen låst nivå som gömmer det du kom för, och inget tjatar om uppgradering efter några diffar.
Inte i en och samma vy. Verktyget är byggt kring två paneler, så du jämför exakt två versioner åt gången. För ett trevägsfall, säg en funktion på main, på en feature-branch och i en kollegas Slack-inklistring, kör det två gånger: main mot branchen, sedan branchen mot inklistringen. Att läsa två rena diffar i tur och ordning slår att kisa på tre kolumner. För en riktig N-vägs- eller branch-medveten jämförelse är det ett git-jobb på ett utcheckat repo, inte ett inklistringsverktyg.
Båda. Diffen är ren JavaScript på klientsidan utan serveranrop, så när sidan väl laddats kan du bryta uppkopplingen och den fortsätter fungera, vilket är praktiskt på en låst build-maskin eller bakom ett ostadigt VPN. På en telefon staplas de två panelerna vertikalt och nyp-zoom fungerar, men kod är ärligt talat lättare att läsa på en laptop där de två versionerna ryms sida vid sida och indenteringen ligger i linje.
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å.