Enkoder i dekoder JWT

Enkoduj i dekoduj tokeny JWT (JSON Web Token). Walidacja podpisu HS256/RS256. Podgląd header, payload, signature. Bezpłatnie.

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Ustawienia

Alg

Secret

Add times Opcja narzędzia

Exp minutes

Payloadów json

151 znaków

Header json

18 znaków

Wynik

Algorytm

HS256 (HMAC SHA-256)

silnik wymusza w nagłówku alg wybrany z selekty

Rozmiar tokena

295 B

header.payload.signature plus dwie kropki

Liczba claimów

claimy z payloadu; przy „Add times” dochodzą iat i exp

Podpis

43 znaków

Base64URL: 43 = HS256, 64 = HS384, 86 = HS512

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRGV2ZWxvcGVyIiwiYWRtaW4iOmZhbHNlLCJzY29wZSI6InJlYWQ6cHJvamVjdHMiLCJhdWQiOiJ0b29sc3RpIiwiaXNzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbSIsImlhdCI6MTc5MjU0MDQ4OCwiZXhwIjoxNzkyNTQ0MDg4fQ.amz-XueadSh6-CzAtHsBkwvy_TDuEqXzaddJzKyL09k

Ściąga: algorytmy, które podpisuje to narzędzie (rodzina HS z HMAC)

Silnik woła hash_hmac(skrót, header.payload, sekret) — obsługuane są wyłącznie HS256/HS384/HS512, opcja w selekcie HS256 jest domyślna
Algorytm	Funkcja skrótu w silniku	Skrót (B)	Podpis Base64URL	Kiedy używać
HS256	sha256 (HMAC SHA-256)	32	43 znaków	domyślny wybór narzędzia — szybki, standard de facto dla API
HS384	sha384 (HMAC SHA-384)	48	64 znaków	dłuższy skrót dla wymagających wdrożeń
HS512	sha512 (HMAC SHA-512)	64	86 znaków	najdłuższy podpis — największy token i koszt hashowania

Ściąga: struktura tokena header.payload.signature

Trzy segmenty sklejone kropkami; Base64URL bez dopełnienia, JSON czytelny dla każdego po dekodowaniu
Część	Co zawiera	Kodowanie
header	typ (domyślnie JWT) i alg — silnik zawsze nadpisuje alg wybranym z selekty	JSON → Base64URL (rtrim „=”, zamiana +/ na -_)
payload	claimy (sub, name, aud…); przy „Add times” doklejane są iat oraz exp = teraz + minuty × 60	JSON → Base64URL, czytelne dla każdego po dekodowaniu
signature	HMAC-SHA-X nad tekstem „header.payload” z użyciem sekretu z formularza	surowy skrót → Base64URL; weryfikacja odtwarza skrót po stronie serwera

Uwaga: tokeny generowane tutaj służą wyłącznie do testów i nauki — nie podpisuj nimi prawdziwych sesji. Nie wpisuj w polu „Secret” sekretu z produkcji: narzędzie pokazuje strukturę i działanie HMAC, a token podpisany znanym lub słabym sekretem (jak w przykładzie „change-me-to-a-strong-secret”) da się podrobić w sekundę. Prawdziwe wdrożenie wymaga długiego, losowego sekretu przekazywanego wyłącznie przez konfigurację serwera oraz walidacji algorytmu i claimów (exp, iss, aud) przy każdym żądaniu.

Warto wiedzieć — tokeny JWT w praktyce

JWT podpisany, nie zaszyfrowany

Podpis gwarantuje nienaruszalność treści, ale nie tajność: segment payload to zwykły Base64URL — każdy, kto dostanie token, odczyta claimy bez sekretu. Nie wkładaj do payloadu haseł ani danych osobowych, których klient nie powinien zobaczyć; do tajności służy JWE albo zwykłe szyfrowanie transportowe.

Rodzina HS: jeden wspólny sekret

HS256/384/512 to HMAC — ten sam sekret podpisuje i weryfikuje, więc musi znać go nadawca i odbiorca. Wygodne w jednej aplikacji; w mikroserwisach zwykle wybiera się asymetryczne RS256/ES256 (klucz publiczny weryfikuje bez możliwości podpisywania). Weryfikator musi też odmówić tokenów z alg spoza listy — atak „alg: none” korzystał właśnie z braku tej kontroli.

Claimy i czasy życia

Opcja „Add times” dokleja do payloadu iat (moment podpisania) i exp = teraz + minuty × 60 (walidacja pozwala do 10 080 minut, czyli tygodnia). Krótki exp to podstawowa higiena: skradziony token umiera sam, a odświeżanie sesji robi osobny refresh token, nie wieczny JWT.

Gdzie JWT spotykasz na co dzień

Najczęściej w nagłówku Authorization: Bearer … przy API i logowaniu SSO (OpenID Connect). Serwer weryfikuje podpis i czasy bez sesji w bazie — token sam niesie tożsamość (sub) i uprawnienia (scope). Zestaw claimów iat/exp/iss/aud pokrywa większość potrzeb typowego API.

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Koder i dekoder JWT — analizuj tokeny JSON Web Token

Koder i dekoder JWT to narzędzie online dla deweloperów umożliwiające dekodowanie, analizowanie i weryfikację tokenów JWT (JSON Web Token). Wklej token, aby natychmiast zobaczyć jego nagłówek, payload i sygnaturę — bez potrzeby pisania kodu.

Czym jest JWT?

JWT (JSON Web Token) to otwarty standard (RFC 7519) definiowania bezpiecznego, kompaktowego sposobu przekazywania informacji między stronami jako obiekt JSON. JWT są powszechnie używane w systemach uwierzytelniania i autoryzacji — szczególnie w architekturach RESTful API i aplikacjach Single Page Application (SPA).

Token JWT składa się z trzech części oddzielonych kropkami: header.payload.signature. Każda część jest zakodowana Base64Url. Header zawiera typ tokenu (JWT) i algorytm szyfrowania (HS256, RS256, ES256). Payload zawiera claims — twierdzenia o użytkowniku (sub, email, role) i tokenie (iat — issued at, exp — expiration). Signature jest podpisem weryfikującym autentyczność tokenu.

Jak używać dekodera JWT?

Wklej token JWT w pole tekstowe. Narzędzie automatycznie dekoduje Base64Url każdej sekcji i wyświetla: zawartość nagłówka (algorytm, typ) w czytelnym JSON, zawartość payload (claims użytkownika i tokenu) z automatycznym parsowaniem dat (iat, exp, nbf z timestamp na czytelną datę), ostrzeżenie o wygaśnięciu tokenu (jeśli exp jest w przeszłości) oraz strukturę sygnatury. Weryfikacja podpisu wymaga klucza sekretnego (HS256) lub klucza publicznego (RS256) — bez nich możemy jedynie zdekodować, nie zweryfikować.

Bezpieczeństwo JWT — co warto wiedzieć?

JWT są podpisane, nie szyfrowane (chyba że używasz JWE). Oznacza to, że payload jest tylko zakodowany Base64Url — każdy, kto ma token, może go zdekodować i odczytać claims. Nigdy nie umieszczaj w JWT poufnych danych (haseł, danych karty kredytowej). Zawsze ustawiaj krótki czas ważności (exp) — tokeny dostępu zazwyczaj 15 minut do 1 godziny, tokeny odświeżania — kilka dni. Używaj HTTPS — token przesyłany przez niezaszyfrowane połączenie może zostać przechwycony.

Typowe claims w JWT

sub (subject) — identyfikator użytkownika. iat (issued at) — czas wystawienia tokenu (Unix timestamp). exp (expiration) — czas ważności tokenu. nbf (not before) — token ważny dopiero od tego momentu. iss (issuer) — wystawca tokenu. aud (audience) — dla kogo przeznaczony. jti (JWT ID) — unikalny identyfikator tokenu.

Najczęściej zadawane pytania

Czy dekodowanie JWT przez to narzędzie jest bezpieczne?

Narzędzie działa po stronie klienta (w przeglądarce) — token nie jest wysyłany na serwer. Dekodowanie Base64 odbywa się lokalnie w JavaScript. Jednak dla tokenów produkcyjnych zawierających wrażliwe dane, zawsze preferuj lokalne narzędzia deweloperskie (np. jwt.io w trybie offline lub narzędzia CLI).

Jaka jest różnica między HS256 a RS256 w JWT?

HS256 (HMAC SHA-256) używa jednego tajnego klucza do podpisywania i weryfikowania — prostszy, ale klucz musi być znany zarówno wystawcy, jak i weryfikatorowi. RS256 (RSA SHA-256) używa pary kluczy: prywatnego do podpisywania i publicznego do weryfikacji — bezpieczniejszy w systemach rozproszonych, gdzie różne serwisy weryfikują tokeny.

Jak sprawdzić, czy token JWT wygasł?

Sprawdź wartość claim exp — jest to Unix timestamp (sekundy od 1970-01-01). Jeśli exp jest w przeszłości (mniejszy niż aktualny timestamp), token wygasł. Nasz dekoder automatycznie konwertuje timestamp na czytelną datę i wyświetla ostrzeżenie, jeśli token wygasł.

Czy można zmienić payload tokenu JWT?

Technicznie tak — można zdekodować, zmodyfikować i ponownie zakodować Base64. Jednak bez znajomości klucza sekretnego (HS256) lub klucza prywatnego (RS256) nie można wygenerować prawidłowej sygnatury. Serwer weryfikujący token odrzuci token z nieprawidłową sygnaturą.

Gdzie przechowywać token JWT w aplikacji webowej?

Najpopularniejsze opcje to: localStorage/sessionStorage (wygodne, ale podatne na ataki XSS), HttpOnly cookies (bezpieczniejsze — niedostępne dla JavaScript, chronione przed XSS), memory (zmienna JS — najbezpieczniejsze, ale token znika po odświeżeniu strony). Dla aplikacji produkcyjnych zalecane są HttpOnly cookies z atrybutem Secure i SameSite=Strict.