Wklej wersję A po lewej, wersję B po prawej, i zobacz, co dokładnie się zmieniło. Bez git clone, bez IDE, bez rejestracji. Wszystko działa w Twojej przeglądarce.
Darmowe narzędzie w przeglądarce do porównywania dwóch wersji kodu bez otwierania Git, GitHub czy IDE. Wklej starą wersję po lewej, nową po prawej, a różnice zostaną podświetlone znak po znaku. Tekst nigdy nie opuszcza Twojej maszyny, co ma znaczenie, gdy fragment pochodzi z private repo lub niezmergeowanej gałęzi.
Powstało dla momentu, gdy kolega wrzuca dwie wersje funkcji na Slacku i pyta "co się zmieniło?". Stawianie lokalnego checkoutu dla 12-liniowego diffa to przerost. Otwieranie widoku PR w GitHubie, kiedy PR jeszcze nie istnieje, też. Dwa panele tekstu, jeden diff, gotowe w piętnaście sekund.
To nie zastępuje git diff na prawdziwym working tree. Nie zrobisz stage hunków, nie zaaplikujesz patcha, nie odpalisz blame. Robi natomiast to, czego potrzebujesz najczęściej: bierze dwa dowolne bloki tekstu i pokazuje edycje między nimi. Pod spodem ten diff to ten sam silnik, który napędza nasze narzędzie compare-text, tu ułożony pod code review.
Diff biegnie znak po znaku, potem przejście semantycznego cleanupu grupuje zmiany w czytelne kawałki, dzięki czemu podświetlenie ląduje na zmienionym identyfikatorze, a nie na każdej pojedynczej literze w środku. Wstawienia w prawym panelu są zielone; usunięcia w lewym są czerwone. Oba panele scrollują się w sposób związany; gdy znajdziesz zmianę w linii 80 po jednej stronie, druga skoczy razem z Tobą.
Czemu poziom znaków, a nie linii? Bo dla krótkich snippetów widok tylko po liniach jest zbyt zgrubny. Zmiana nazwy zmiennej z id na userId to jedna zmiana identyfikatora; diff po liniach pokazałby całą linię jako usuniętą i całą nową jako wstawioną, technicznie poprawnie, ale właściwą edycję trudniej dostrzec. Tryb znakowy z semantycznym cleanupem podświetla zmieniony token, a resztę linii zostawia w spokoju. W długich plikach kompromis się odwraca i dlatego Git domyślnie używa klasycznego diff opartego na liniach. Oba mają swoje miejsce. To narzędzie daje widok przyjazny snippetom.
Czego narzędzie świadomie nie robi: nie zna składni. Nie parsuje JavaScriptu, Pythona ani Javy. Blok przeformatowany z taką samą semantyką nadal pokaże się jako diff, bo dla porównywarki tekstu to inny tekst. Jeśli potrzebujesz diffa świadomego formatu dla payloadów strukturalnych, nasza strona compare-json robi to dla JSON, compare-yaml dla YAML, a compare-xml dla XML i plików POM. Dla surowego kodu źródłowego diff tekstowy plus własne oczy są zwykle szybsze niż konfigurowanie narzędzia syntaktycznego pod jednorazowy snippet.
Dwa panele tekstu, jeden diff. Bez logowania, bez uploadu, bez formatu patcha do parsowania.
Skopiuj starą wersję funkcji, pliku lub snippetu z edytora, terminala lub skądkolwiek. Ctrl+C, potem wklej do lewego panelu. Jeśli pobierasz z git show <commit>, skopiuj treść pliku, a nie nagłówek patcha, żeby diff podświetlał tylko realne zmiany kodu.
To samo z nową wersją. Jeśli kolega wkleił ją na Slacku, w Teams lub w mailu, kopiuj wprost stamtąd. Spacje i wcięcia są zachowywane przy wklejaniu, co ma znaczenie w językach, gdzie wcięcie jest istotne, jak Python i YAML. Tab vs spacje pojawi się jako różnica, jeśli oba snippety się rozjeżdżają.
Usunięcia są przekreślone na czerwono po lewej; wstawienia na zielono po prawej. Liczniki zmian w każdym nagłówku mówią, ile odrębnych edycji wykryto. Przeczytaj podświetlenia, skup się najpierw na zmianach logiki (przepływ sterowania, warunki, obsługa błędów), a same zmiany nazw lub formatowania traktuj jako niższy priorytet w przejściu rewizyjnym.
Ktoś wrzuca dwa bloki kodu na czacie i pyta, który jest poprawny. Klonowanie repo, przełączanie gałęzi i otwieranie IDE dla dwudziestu linii to zmarnowany wysiłek. Wklej oba do narzędzia diff i masz odpowiedź, zanim przyjdzie kolejna wiadomość. To najczęstszy powód, dla którego ludzie sięgają po diff online.
Pipeline'y CI, Dockerfile, package.json oraz YAML workflow GitHub Actions dryfują bez przerwy. Kolega edytuje .github/workflows/ci.yml na gałęzi, build się sypie, a Ty chcesz zobaczyć, co się zmieniło, bez checkoutu jego gałęzi. Wklej wersję z main obok wersji z popsutej gałęzi, a winowajca-step zwykle wypływa w sekundy. Specjalnie dla plików workflow nasza strona diff YAML czyściej radzi sobie z przypadkami brzegowymi wcięć.
Product managerowie, projektanci i account managerowie czasem muszą wiedzieć, co robi zmiana w kodzie, bez czytania interfejsu Gita. Widok PR w GitHubie zakłada zaznajomienie ze składnią diffa, drzewem plików i komentarzami rewizji. Wklejenie przed-i-po do czystego widoku dwóch paneli i przejście przez podświetlenia razem jest dużo bardziej przyjazne. Przydaje się też w postmortemach incydentów, gdy w gronie są osoby spoza inżynierii.
Masz wyjście git show abc123 i git show def456 dla pliku z dwóch commitów, może z loga CI lub zdalnego sandboxa, gdzie nie odpalisz wygodnie poleceń git. Zdejmij nagłówki patcha, wklej dwie zawartości pliku i zrób diff. Działa dobrze, gdy debugujesz na serwerze, czytasz artefakt builda lub przeglądasz security advisory cytujące zawartości plików z dwóch konkretnych commitów.
Dostawca wysyła przykładową integrację w PDF. Regulator mailem przesyła snippet polityki w kodzie. Konsultant załącza spatchowaną wersję Twojego skryptu. Żadne z tego nie przychodzi jako klonowalne repo. Skopiuj tekst z PDF lub maila, wklej obok aktualnej wersji i masz użyteczną powierzchnię rewizji w mniej niż minutę. Spodziewaj się trochę szumu formatu z kopiowania z PDF; łamania linii i znaki cudzysłowu to zwykli sprawcy.
Sytuacje, w których diff czystego tekstu nie zgadza się z tym, co pokazałby Git, Twoje IDE lub narzędzie code review. Warto przebiec wzrokiem, zanim wkleisz kod produkcyjny i zaczniesz martwić się fałszywym alarmem.
| Topic | What this tool does |
|---|---|
| Końce linii (CRLF vs LF) | CRLF w stylu Windows i LF w stylu Unix to różne bajty. Plik wklejony z edytora windowsowego i plik wklejony z linuksowego kontenera pokażą się jako diff całego pliku, jeśli końce linii się rozjeżdżają, nawet przy identycznym widocznym tekście. Git normalizuje to przez core.autocrlf; to narzędzie nie. |
| Białe znaki na końcu linii | Spacje lub taby na końcu linii pokażą się jako różnica. core.whitespace Gita może ostrzegać lub auto-poprawiać przy commicie; tu, co wklejasz, to porównujesz. Jeśli podłoga szumu Twojego code review jest pełna edycji końcowych białych znaków, wytnij je w edytorze przed diffem. |
| Pliki binarne | To narzędzie jest tylko do tekstu. Wklejenie zawartości pliku binarnego (PNG, skompilowany JAR, sqlite DB) wyprodukuje śmieci albo zawiesi kartę. Dla diffa binarnego Git pokazuje "Binary files differ" zamiast patcha; do realnej zawartości potrzebujesz narzędzi specyficznych dla formatu. |
| Oznaczenie text vs binary w .gitattributes | .gitattributes repo może nadpisać detekcję text-vs-binary Gita per wzorzec pliku. To ustawienie nie jeździ z kopiuj-wklej. Jeśli podejrzewasz, że plik jest traktowany inaczej w dwóch checkoutach, to ten plik trzeba sprawdzić; to narzędzie i tak zrobi diff jako czysty tekst. |
| Diff znakowy vs liniowy | Ta strona używa diffa znakowego z semantycznym cleanupem. Git domyślnie idzie po liniach, opcjonalnie z git diff --word-diff dla poziomu słowa. Znakowy najlepszy dla krótkich snippetów, gdzie zmienił się jeden token; liniowy najlepszy dla długich plików, gdzie zmieniło się wiele linii hurtem. |
| git diff --word-diff | Tryb --word-diff Gita podświetla zmiany na poziomie słowa wewnątrz linii, bliżej tego, co robi tu narzędzie dla snippetów. Format wyjścia jest inny (markup przyjazny terminalowi vs panele obok siebie), ale intencja się pokrywa. Jeśli żyjesz w terminalu, --word-diff jest lokalnym odpowiednikiem. |
| Progi dużych plików | Diff w przeglądarce odpowiada żwawo do kilku tysięcy linii na stronę. Powyżej semantyczny cleanup zwalnia, a wyrenderowany DOM staje się ciężki. Dla ogromnych plików uruchom git diff lokalnie i przepuść przez pager albo rozbij porównanie na mniejsze sekcje. |
| Kodowanie (tylko UTF-8) | Diff zakłada wejście UTF-8, co w 2026 pokrywa niemal cały kod źródłowy. Pliki zapisane jako UTF-16, Windows-1252 lub Shift-JIS mogą po wklejeniu wyglądać jak mojibake, zależnie od przeglądarki. Jeśli snippet wygląda na pomieszany, zapisz plik źródłowy ponownie jako UTF-8 przed kopiowaniem. |
Lokalny git diff porównuje dwa refy (commity, gałęzie, working tree) wewnątrz prawdziwego repozytorium. Zna Twój index, worktree i historię. To narzędzie online nic z tego nie robi. Porównuje dwa dowolne bloki tekstu, które wklejasz. Używaj git diff do realnej rewizji na repo z checkoutem. Używaj tego, gdy masz dwa snippety i nie ma wygodnego sposobu wsadzić ich w working tree, albo gdy chcesz widoku obok siebie bez przełączania kontekstu.
Nie do końca. GitHub i GitLab używają liniowego unified diffa z kontekstem pliku, nagłówkami hunków i podsumowaniami per plik. To narzędzie używa diffa znakowego z semantycznym cleanupem, lepszego dla krótkich snippetów i gorszego dla całych plików z wieloma zmianami. Do realnej rewizji pull requesta przejdź do widoku PR GitHuba. Do szybkiego porównania snippetów poza PR, to jest szybsze i nie zmusza do nawigacji do właściwego repo.
Nie. To diff czystego tekstu. Nie parsuje języka, więc nie wie, że zmieniona zmienna to ten sam identyfikator w 12 miejscach, i nie umie zignorować przeformatowanych białych znaków tak, jak diff świadomy składni. W większości rewizji snippetów to wystarcza, bo podświetlenia czytasz własną głową. Jeśli potrzebujesz prawdziwie semantycznego diffa kodu, Twoje IDE (VS Code, IntelliJ) lub diff oparty na tree-sitter to właściwe narzędzie. Ta strona optymalizuje pod prędkość, nie pod głębokie parsowanie.
Klasyczne unixowe diff -u produkuje patcha w formacie unified (tym samym, którego Git używa wewnętrznie). Jest liniowe i zaprojektowane jako maszynowo czytelne, żebyś mógł zaaplikować patch gdzie indziej. To narzędzie jest czytelne dla człowieka. Pokazuje dwa panele obok siebie z inline'owym podświetleniem zamiast jednej kolumny linii z plusami i minusami. Nie produkuje pliku patcha do zaaplikowania git apply czy patch -p1. Jeśli musisz wygenerować patcha, użyj linii poleceń. Jeśli musisz przeczytać diffa, to jest przyjaźniejsze.
Tak, ale po swojemu. Końce linii CRLF (Windows) i LF (Unix) pojawią się jako różnica, jeśli oba wklejone snippety nie są zgodne, bo to technicznie różne bajty. Z białymi znakami na końcu linii tak samo. Jest to zgodne z tym, jak Git traktuje pliki, gdy core.autocrlf jest wyłączone. Jeśli zależy Ci tylko na zmianach logiki, a nie na białych znakach, przytnij każdy panel przed wklejeniem. Aktualnie nie oferujemy przełącznika "ignoruj białe znaki", ale jest na roadmapie; git diff -w to lokalny odpowiednik.
Praktycznie tak. Diff działa w Twojej przeglądarce, więc bardzo duże wejścia (cała zwendorowana biblioteka albo wygenerowany plik na 50 000 linii) spowalniają stronę lub zatrzymują kartę zależnie od pamięci przeglądarki. Dla typowej rewizji kodu (funkcje, pliki, skrypty build, configi do kilku tysięcy linii na stronę) diff kończy się praktycznie natychmiast. Jeśli musisz porównywać całe repozytoria, prawdziwe narzędzie Git lub porównywarka folderów to właściwa odpowiedź; ta strona jest zrobiona pod snippety i pojedyncze pliki.
Twój kod nigdy nie opuszcza przeglądarki. Diff, podświetlanie i renderowanie działają na Twojej maszynie. Nie wysyłamy tekstu na serwer, nie logujemy go ani nie przekazujemy żadnej trzeciej stronie. Ma to znaczenie szczególnie przy rewizji kodu objętego prawem własności: wklejenie niewydanej funkcji, łatki bezpieczeństwa lub fragmentu z private repo do usługi w chmurze samo w sobie może łamać politykę przetwarzania danych Twojego pracodawcy. Weryfikacja jest prosta. Otwórz DevTools przeglądarki, przełącz się na zakładkę Network, wklej obie wersje i obserwuj. W trakcie porównania nie ma żadnych żądań wychodzących. Ten sam model prywatności obowiązuje w naszych innych narzędziach, w tym compare-text, compare-json i compare-yaml. Code review działa najlepiej, gdy powierzchnia rewizji jest godna zaufania.