Skip to content

Porównanie tekstów i Diff

Porównaj dwa teksty natychmiast w przeglądarce. Widok obok siebie, podświetlanie słów, eksport unified diff, opcje ignorowania wielkości liter/spacji/pustych wierszy. 100 % w przeglądarce — bez przesyłania.

Bez śledzenia Działa w przeglądarce Bezpłatne
Każde porównanie działa lokalnie w Twojej przeglądarce. Tekst nie opuszcza tego urządzenia.
Opcje ignorowania
Sprawdzono parytet z wyjściem `diff -u`, poprawność intra-line LCS oraz dostępność (role ARIA, ogłaszanie zmian przez czytniki ekranu, obsługa RTL/LTR). — Go Tools Text Tooling Team · May 21, 2026

Czym jest Text Diff?

Text diff to strukturalne porównanie dwóch dokumentów tekstowych, które znajduje najmniejszy zestaw wstawień i usunięć przekształcający jeden w drugi. Wynik czyni zmianę widoczną: zielony dla wierszy dodanych, czerwony dla usuniętych, obok siebie lub w postaci unified patch (format `---/+++/@@` używany przez `git`, GitHub i uniksowe polecenie `patch`).

Pod maską każdy nowoczesny diff to algorytm Longest Common Subsequence (LCS). Praca Eugene'a Myersa z 1986 roku o O((N+M)D) jest kanoniczną wydajną implementacją; klasyczne programowanie dynamiczne (używane tutaj, z obcinaniem wspólnych prefiksów/sufiksów) jest prostsze i działa świetnie dla typowych wejść webowych. Po wyrównaniu wierszy sąsiednie pary usunięcie+dodanie przechodzą przez drugi LCS na poziomie tokenów, dzięki czemu renderer może podświetlić tylko te słowa, które naprawdę zmieniły się w wierszu — to, co recenzenci nazywają intra-line lub word-level diff.

Dlaczego nie porównywać po prostu znak po znaku? Bo edycje rzadko są płaskie: wstawienie jednego wiersza w środek pliku ze 200 wierszami przesuwa każdy poniżej. Naiwne `===` uznałoby wszystkie 199 wierszy za różne. LCS mówi prawdę: dodany jeden wiersz, 199 bez zmian.

To narzędzie wykonuje całe porównanie w Twojej przeglądarce. Bez przesyłania, bez plików tymczasowych, bez logów. Bezpieczne dla kodu firmowego, redlinowanych umów, prywatnych logów — wszystkiego, czego nie chciałbyś wkleić na obcy serwer. Musisz porównać JSON? Użyj strukturalnego JSON Diff, by kolejność kluczy i białe znaki przestały być szumem. Porównujesz dwa configi w YAML lub CSV? Najpierw konwertuj przez YAML to JSON albo JSON to CSV, a potem diffuj odpowiednim narzędziem dla formatu.

// Two strings that look 'mostly the same' but a naïve check disagrees
const a = 'hello world';
const b = 'hello, world!';

// Character equality
a === b; // false — but only 3 characters actually changed.

// LCS-style diff (this tool, at line + word granularity)
// → 1 line modified, inline highlight: 'hello[, ]world[!]'
// → unified patch:
//   --- original
//   +++ modified
//   @@ -1 +1 @@
//   -hello world
//   +hello, world!

Kluczowe funkcje

Side-by-Side + Unified

Przełączaj między wizualnym widokiem dwukolumnowym (do recenzji ludzkiej) a kanonicznym formatem łatki unified-diff (do `git apply`, narzędzi code review, raportów błędów).

Podświetlanie wyrazów inline

Gdy dwa wiersze są sparowane jako zmodyfikowane, kolorowe tło noszą tylko zmienione tokeny. Wzrok natychmiast znajduje edycję zamiast skanować 80 znaków.

Ignorowanie wielkości liter / białych znaków / pustych wierszy

Cztery niezależne przełączniki: wielkość liter, wszystkie białe znaki, tylko końcowe białe znaki, puste wiersze. Replikuje `git diff -i -w -b` w kilku kliknięciach.

Eksport unified diff

Skopiuj czystą łatkę `---/+++/@@` z trzema wierszami kontekstu. Wpada bezpośrednio do komentarza PR, raportu błędu lub `patch -p1`.

100% w przeglądarce

Wejścia nigdy nie opuszczają Twojego urządzenia. Bez przesyłania, bez analityki tekstu. Działa offline po załadowaniu strony. Bezpieczne dla kodu firmowego i poufnej prozy.

Świadomość Unicode + RTL

Dzieli tokeny na granicach słów Unicode. Treści arabskie, hebrajskie, CJK porównują się czysto; warianty zakończeń wierszy (CRLF, LF, CR) są normalizowane.

Przykłady

Code review — zmiana nazwy jednej zmiennej

function getUser(id) {
  const u = db.users.find(x => x.id === id);
  return u;
}
function getUser(userId) {
  const u = db.users.find(x => x.id === userId);
  return u;
}

Widok obok siebie podświetla każdy wiersz zawierający zmianę nazwy, a inline word diff przyciemnia niezmienione tokeny — recenzent od razu widzi, który identyfikator został zmieniony.

Edycja umowy — dodana jedna klauzula

1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
3. Disputes are resolved in California courts.
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.

Jedyną różnicą jest wstawiona klauzula (wiersz 2a). Otaczający kontekst pozostaje czysty — przydatne przy redlining umów lub dokumentów polityki.

Analiza logów — zmieniony czas żądania

GET /api/users 200 14ms
POST /api/orders 201 88ms
GET /api/orders/42 200 21ms
GET /api/users 200 14ms
POST /api/orders 201 4200ms
GET /api/orders/42 500 21ms

Dwa wiersze ulegają zmianie. Podświetlenie inline pokazuje dryf opóźnień 88ms → 4200ms i kod statusu 200 → 500. Standardowe podejście dla osi czasu incydentu.

Białe znaki na końcu — przełącz „Ignoruj końcowe”

  margin: 0;  
  padding: 0;
  border: none;
  margin: 0;
  padding: 0;
  border: none;

Bez tej opcji wiersz 1 zgłasza różnicę (spacje na końcu). Włącz „Ignoruj spacje / taby na końcu wiersza”, a diff spadnie do zera — ten sam trik co `git diff -b`.

Jak korzystać

  1. 1

    Wklej obie wersje

    Tekst oryginalny po lewej, zmieniony po prawej. Live diff renderuje się podczas pisania; duże wejścia (>200 KB łącznie) przełączają się na ręczny przycisk Diff.

  2. 2

    Włącz potrzebne opcje ignorowania

    Ignoruj wielkość liter, wszystkie białe znaki, spacje końcowe lub puste wiersze — każda niezależna, pamiętana między wizytami.

  3. 3

    Przeczytaj diff lub zabierz łatkę

    Side-by-Side do recenzji ludzkiej, Unified do formatu łatki `---/+++/@@`. „Kopiuj unified diff” wysyła czystą łatkę do schowka na potrzeby code review lub `patch -p1`.

Typowe pułapki diff

Cały plik „zmieniony” po kopii Windows-vs-Unix

Jeśli wklejasz z Notatnika na Windows do oryginału edytowanego pod Uniksem, każdy wiersz pokaże różnice \r. Włącz „Ignoruj spacje / taby na końcu wiersza”, by wyciszyć znaki CR.

✗ Niepoprawne
Diff: 200 modifications (all because of trailing \r)
✓ Poprawne
Ignore trailing spaces / tabs → 2 real changes

Diff krzyczy z powodu wcięć

Przeformatowanie tabów ↔ spacji rozsadza diffy wierszowe. „Ignoruj wszystkie białe znaki” zwija diff do prawdziwych zmian semantycznych.

✗ Niepoprawne
Diff: 87 modifications (all are indent changes)
✓ Poprawne
Ignore all whitespace → 4 actual changes

Identyczne akapity oznaczone z powodu jednego pustego wiersza

Dodanie lub usunięcie jednej pustej linii w prozie może rozjechać cały region. „Ignoruj puste wiersze” to naprawia, nie tykając treści.

✗ Niepoprawne
Diff: paragraph 2 'completely changed' (one blank line moved)
✓ Poprawne
Ignore blank lines → no changes in paragraph 2

Diff mówi „identyczne”, ale pliki są różne

Niemal zawsze to opcja ignorowania wielkości liter lub białych znaków pozostawiona z poprzedniej sesji. Otwórz panel opcji ignorowania — wszystkie przełączniki tam są. Wyłącz wszystkie, jeśli chcesz porównania bajt po bajcie.

✗ Niepoprawne
0 differences shown, but `cmp` says the files differ
✓ Poprawne
Disable all Ignore options → real diff appears

Wklejony JSON wygląda jak „wszystko się zmieniło”

Text diff traktuje kolejność kluczy jako istotną; JSON — nie. Dla payloadów JSON używaj dedykowanego narzędzia JSON Diff — ignoruje kolejność kluczy i respektuje ścisłość typów.

✗ Niepoprawne
Text diff on JSON: 100% of lines changed (just a key reorder)
✓ Poprawne
<a href="/pl/tools/json-diff">JSON Diff</a>: 0 differences

Ostrzeżenie o obcięciu diffu zignorowane

Powyżej 5 000 wierszy na stronę wejście jest obcinane. Jeśli pojawi się ostrzeżenie, przełącz się na `diff -u file1 file2` lub `git diff --no-index` z wiersza poleceń — oba strumieniują i obsługują gigabajty.

✗ Niepoprawne
Pasted a 20,000-line log — only first 5,000 lines diffed
✓ Poprawne
`diff -u a.log b.log` in terminal handles full file

Typowe zastosowania

Snippet do code review
Wrzuć dwie wersje funkcji do pól, by zobaczyć zmianę nazwy, usuniętą gałąź lub nową klauzulę guard jednym spojrzeniem. Podświetlanie słów inline jest szybsze niż skanowanie diffu GitHub w poszukiwaniu jednoliniowej zmiany.
Redline umowy / polityki
Wklej wczorajszą umowę i dzisiejszą wersję. Wstawione klauzule wyskakują; niezmienione akapity przygasają do szarości. Eksportuj unified patch jako ślad recenzji prawnej.
Analiza osi czasu logów
Porównaj wycinek logów SRE sprzed incydentu z wycinkiem z trakcie incydentu. Dryf opóźnień, kodów statusu i częstotliwości wypływa natychmiast, bez `awk`.
Korekta prozy / wersji roboczej
Wklej wersję roboczą i wersję redaktora. Inline word diff pokazuje dokładnie, które zdania zostały przeredagowane — nieocenione przy akceptowaniu lub odrzucaniu zmian pojedynczo.
Recenzja tłumaczenia
Diffuj stare tłumaczenie z nowym, by potwierdzić, że nowa wersja zachowuje sens, strukturę i placeholdery. Włącz „Ignoruj spacje końcowe”, by wyciszyć szum, który tłumacze często wprowadzają.
Audyt plików konfiguracyjnych / .env
Porównaj dwa pliki `.env`, `docker-compose.yaml` lub shell rc. Z włączoną opcją „Ignoruj puste wiersze” diff skupia się na różnicach funkcjonalnych zamiast na szumie formatowania.

Szczegóły techniczne

LCS z obcinaniem prefiksu/sufiksu
Wspólne wiodące i końcowe wiersze są obcinane przed uruchomieniem programowania dynamicznego LCS. Diff „dwa configi po 2 000 wierszy z jednym zmienionym wierszem” zwija się do tabeli DP 1×1 i renderuje się w czasie krótszym niż milisekunda.
Diff intra-line na poziomie tokenów
Sąsiednie bloki usunięcia + dodania są parowane i tokenizowane po ciągach Unicode słów / nie-słów / białych znaków. Drugi przebieg LCS produkuje zielone/czerwone zakresy tokenów, które czynią zmodyfikowane wiersze czytelnymi.
Unified diff = zgodny z git/patch
Wyjście jest zgodne z formatem `---/+++/@@ -L,C +L,C @@` zdefiniowanym dla GNU patch i używanym przez Git, GitHub i każde narzędzie code review. Aplikuj przez `pbpaste | patch -p0`.
Limit wejścia 5 000 wierszy na stronę
Powyżej limitu diff jest obcinany i ostrzega. Dla wejść wielomegabajtowych użyj `diff -u` lub `git diff --no-index` z wiersza poleceń — strumieniują i obsługują gigabajty.

Najlepsze praktyki

Wybierz opcje ignorowania przed czytaniem
Szum od spacji końcowych, CRLF i wielkości liter zagłusza sygnał. Najpierw włącz odpowiednie opcje; diff czyta się znacznie łatwiej, a Ty nie uczysz się prześlizgiwać obok „fałszywych” zmian.
Unified do udostępniania, Side-by-Side do recenzji
Kolumny wizualne są dla Twoich oczu. Łatki unified są dla cudzych terminali. Skopiowany unified diff wpada bez tłumaczenia do wiadomości Slack, komentarza Jira lub `patch -p1`.
Sprawdzenie zdrowego rozsądku przez procent podobieństwa
Jeśli dwa pliki są „prawie takie same”, ale wynik podobieństwa to 30%, masz problem z zakończeniami wierszy lub białymi znakami. Włącz „Ignoruj wszystkie białe znaki” i sprawdź ponownie przed czytaniem diffu.

Często zadawane pytania

Czy wklejany tekst jest wysyłany na Wasz serwer?
Nie. Każde porównanie działa w JavaScript wewnątrz Twojej przeglądarki. Tekst nie jest przesyłany, logowany, zapisywany na dysku ani wysyłany do osób trzecich. W localStorage zapisywane są tylko preferencje interfejsu (tryb widoku i przełączniki ignorowania), aby strona je pamiętała przy następnej wizycie — nigdy tekst. Możesz to zweryfikować w DevTools → Network: po kliknięciu Diff nie leci ani jedno żądanie.
Jaka jest różnica między text diff a JSON diff?
Text diff porównuje wiersz po wierszu — idealny do prozy, kodu, logów, umów, plików konfiguracyjnych. JSON Diff rozumie model danych JSON: kolejność kluczy jest nieistotna, typy są ścisłe, tablice można dopasowywać po kluczu. Jeśli wkleisz JSON do text diff, zmiana kolejności kluczy i różnice w białych znakach zostaną oznaczone jako zmiany; JSON Diff je ignoruje. Używaj text diff dla treści niestrukturalnych, a JSON Diff dla odpowiedzi API i payloadów konfiguracji.
Jak ignorować białe znaki, wielkość liter lub puste wiersze?
Kliknij panel „Opcje ignorowania” nad diffem. „Ignoruj wielkość liter” zrównuje A i a. „Ignoruj wszystkie białe znaki” zwija każdą spację, tab i nową linię przed porównaniem. „Ignoruj spacje / taby na końcu wiersza” usuwa tylko białe znaki z końca wiersza — standardowe zachowanie `git diff -b`. „Ignoruj puste wiersze” odrzuca puste wiersze przed diffem. Każda opcja jest niezależna i pamiętana między wizytami.
Czym jest unified diff (i kiedy go kopiować)?
Unified diff to tekstowy format `---/+++/@@` używany przez `patch`, `git apply`, PR-y GitHub i większość narzędzi code review. Kliknij „Kopiuj unified diff”, aby otrzymać łatkę z trzema wierszami kontekstu wokół każdej zmiany — wklej ją do raportu błędu, komentarza code review lub polecenia `patch -p1`, a zaaplikuje się czysto. Side-by-side jest dla ludzi, unified diff dla maszyn (i recenzentów myślących jak maszyny).
Dlaczego diff pokazuje całe wiersze jako zmienione, gdy edytowałem tylko jedno słowo?
Wcale nie — przyjrzyj się bliżej. Cały wiersz jest podświetlony, bo coś w nim się zmieniło, ale wewnątrz podświetlenia jasne tło niosą tylko zmienione tokeny (zielony dla dodanych, czerwony przekreślony dla usuniętych). To intra-line word diff: kontekst wiersza pozostaje czytelny, a wzrok trafia dokładnie w miejsce edycji. Jeśli dwa sąsiednie wiersze zostały zmienione, oba pokazują podświetlenie inline.
Jak obsługiwane są zakończenia wiersza CRLF i LF?
Oba są rozpoznawane. Diff dzieli po \r\n, \n i pojedynczym \r, więc Windows CRLF, Unix LF i stary Mac CR ustawiają się poprawnie. Jeśli chcesz wyraźnie wychwycić zmiany w zakończeniach wierszy, wyłącz „Ignoruj spacje / taby na końcu wiersza” — \r ujawni się jako znak końcowy. Aby całkowicie wyciszyć szum zakończeń wierszy, włącz „Ignoruj wszystkie białe znaki”.
Jak duże mogą być oba wejścia?
Diff działa na wątku głównym, więc praktyczne granice to około 5 000 wierszy lub 1 MB na stronę; powyżej obcinamy i wyświetlamy ostrzeżenie. Live diff wyłącza się powyżej 200 KB łącznie i przełącza na ręczny przycisk Diff. Dla plików wielomegabajtowych użyj `diff -u` lub `git diff --no-index` z wiersza poleceń — strumieniują i obsługują gigabajty.
A co z diffowaniem kodu? Czy zna mój język?
Diff jest niezależny od języka: widzi wiersze i tokeny, nie składnię. To zaleta dla snippetów review, edycji konfiguracji i wklejonych łatek. Jeśli potrzebujesz semantycznego diffu kodu (zmiana nazwy funkcji między plikami, poziom AST), użyj git, widoku PR GitHub lub dedykowanego strukturalnego narzędzia diff. Dla 90% sytuacji code review — rzut okiem na funkcję, porównanie dwóch snippetów — diff wierszowo-słowny jest dokładnie tym, czego potrzebujesz.
Dlaczego pojedyncza edycja czasem wygląda jak usunięty wiersz plus dodany wiersz?
Gdy w wierszu zmieniło się zbyt wiele, by podświetlanie słów było użyteczne, diff zgłasza to jako oddzielne wiersze usunięcia i dodania, by zachować czystą strukturę. Ta sama heurystyka daje czytelny wynik dla przeredagowanej prozy i bloków kodu, które zostały przepisane, a nie edytowane. Przełącz na widok Unified, by zobaczyć klasyczny format pary `-`/`+` używany w łatkach.
Jak obliczany jest procent podobieństwa?
To liczba niezmienionych wierszy (po zastosowaniu opcji ignorowania) podzielona przez większą z dwóch liczb wierszy, ograniczona do 100%. Dwa identyczne wejścia dają 100%. Dodanie jednego nowego wiersza do pliku ze 100 wierszami daje 99%. Zastąpienie każdego wiersza to 0%. Przydatne do szybkiej oceny „to drobna edycja czy całkowite przepisanie” jeszcze przed czytaniem diffu.
Czy mogę udostępnić diff koledze?
Tak, na dwa sposoby. (1) Kliknij „Kopiuj unified diff” i wklej łatkę do czatu, Slacka lub komentarza PR — każdy z terminalem zaaplikuje ją przez `patch < clip`. (2) Zrób zrzut ekranu panelu side-by-side do recenzji wizualnej. Celowo nie udostępniamy przycisku „Udostępnij przez URL”: wymagałby przesyłania Twojego tekstu, czego nie robimy.
Czy diff obsługuje języki pisane od prawej do lewej, jak arabski lub hebrajski?
Tak, dla zawartości tekstowej — wiersze i tokeny są świadome Unicode. Interfejs używa logicznych kierunków CSS, więc w lokalach RTL gutter i kolumny wierszy odwracają się naturalnie. Wewnątrz komórki diff kierunek tekstu podąża za treścią, więc ciągi arabskie i hebrajskie renderują się poprawnie, a znaczniki +/- pozostają wyrównane do guttera.

Powiązane narzędzia

Zobacz wszystkie narzędzia →