Skip to content

Dekoder JWT

Dekoduj JWT online darmowym dekoderem JWT. Sprawdź header, payload, signature, claims i wygaśnięcie. W 100% w przeglądarce — token nie opuszcza urządzenia.

Bez śledzenia Działa w przeglądarce Bezpłatne
Token JWT
Zweryfikowane pod kątem zgodności z RFC 7519 i gwarancji prywatności — Zespół bezpieczeństwa Go Tools · Apr 22, 2026

Czym jest JWT?

JSON Web Token, czyli JWT (wymawiane „dżot”), to zwarty, bezpieczny dla URL-i format tokena służący do przenoszenia claims między dwiema stronami. Jest zdefiniowany w RFC 7519 i stanowi dominujący format poświadczeń wykorzystywany przez tokeny dostępu OAuth 2.0, tokeny ID OpenID Connect, klucze API u współczesnych dostawców uwierzytelniania (Auth0, Okta, Clerk, Supabase, Firebase) oraz tokeny międzyusługowe w architekturach mikroserwisowych.

„JSON Web Token (JWT) to zwarty format reprezentacji claims przeznaczony dla środowisk z ograniczonym miejscem, takich jak nagłówki HTTP Authorization i parametry zapytań URI.” — RFC 7519, sekcja 1

JWT to trzy obiekty JSON zakodowane w Base64URL i połączone kropkami: header.payload.signature. Header opisuje, jak token jest podpisany (claim alg — na przykład HS256 lub RS256 — oraz claim typ, zwykle „JWT”). Payload niesie claims: zarejestrowane jak iss, sub, aud, exp, iat, plus dowolne własne claims wystawcy (role, scope, email, ID najemcy). Signature to kryptograficzny dowód obliczany na podstawie header i payload kluczem tajnym lub prywatnym wystawcy, dzięki któremu odbiorca może wykryć modyfikacje.

Kluczowe jest to, że JWT jest zakodowany, ale nieszyfrowany. Każdy, kto ma token, może odczytać jego payload — dekodowanie to po prostu Base64URL i parsowanie JSON. Gwarancja bezpieczeństwa wynika z signature: atakujący może odczytać JWT, ale bez klucza podpisującego nie wytworzy innego JWT, który przejdzie weryfikację signature. Dlatego JWT można bezpiecznie przesyłać przez sieć, ale nie wolno ich wypełniać sekretami.

Dekoder JWT pokazuje dokładnie to, co zawiera token — algorytm, claims, datę wygaśnięcia — nie naruszając signature. To najszybsza droga do odpowiedzi na pytania „czy ten token wygasł?”, „jaką rolę ma ten użytkownik?”, „który wystawca wygenerował ten token?” lub „czy to token alg:none, który należy odrzucić?”. Całe dekodowanie w tym narzędziu odbywa się lokalnie w przeglądarce, więc wklejenie żywego tokena produkcyjnego jest bezpieczne.

Praca z JWT często łączy się z innymi narzędziami programistycznymi. Może być potrzebne zdekodowanie segmentu zapakowanego w Base64URL przy debugowaniu źle uformowanego tokena, zdekodowanie nagłówka Authorization z URL po przechwyceniu go z proxy lub ręczna zamiana claim exp na czytelną datę. Aby pogłębić wiedzę o tym, jak JWT są podpisywane, weryfikowane i rotowane na produkcji, warto zajrzeć do naszego przewodnika po podstawach Base64 — Base64URL stanowi fundament każdego JWT.

// Decode a JWT in the browser — header & payload only
function decodeJwt(token) {
  const [h, p, s] = token.split('.');
  const pad = (seg) => seg + '==='.slice((seg.length + 3) % 4);
  const decode = (seg) => JSON.parse(
    atob(pad(seg).replace(/-/g, '+').replace(/_/g, '/'))
  );
  return { header: decode(h), payload: decode(p), signature: s };
}

const { header, payload } = decodeJwt(token);
console.log(header);   // → { alg: 'HS256', typ: 'JWT' }
console.log(payload);  // → { sub: 'user_123', exp: 1999999999, ... }

// Expiration check
const expired = payload.exp * 1000 < Date.now();

Kluczowe funkcje

Natychmiastowe dekodowanie JWT

Wystarczy wkleić token i obserwować, jak JWT dekoduje się w czasie rzeczywistym — header, payload i signature parsowane w locie. Bez przycisku „Zdekoduj”, bez rundy do serwera.

Wykrywanie wygaśnięcia

Automatycznie odczytuje claim exp i wyświetla czerwoną plakietkę, gdy token wygasł, wraz z dokładną datą wygaśnięcia w lokalnej strefie czasowej.

Niezależny od algorytmu

Dekoduje każdy algorytm JWS — HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, EdDSA oraz alg:none.

100% lokalnie

Dekodowanie działa w przeglądarce dzięki natywnym atob i JSON.parse. Token nigdy nie jest wysyłany — bezpieczne dla poświadczeń produkcyjnych.

Świadomy claims widok

Wyróżnia zarejestrowane claims z RFC 7519 (iat, exp, nbf, iss, aud, sub, jti), aby od razu wychwycić problemy z uwierzytelnianiem.

Kopiowanie jednym kliknięciem

Skopiuj JSON header, JSON payload lub surowy signature do schowka jednym kliknięciem — idealne do raportów błędów i testów.

Przykłady

Token HS256 (poprawny)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNTAwMDAwMCwiZXhwIjoxOTk5OTk5OTk5fQ.4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0
{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "user_123",
  "name": "Alice",
  "role": "admin",
  "iat": 1715000000,
  "exp": 1999999999
}

Token podpisany algorytmem HMAC-SHA256, zawierający subject, rolę i datę wygaśnięcia w przyszłości — najczęstszy schemat JWT używany do uwierzytelniania sesji.

Token RS256 (wygasły)

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleS0yMDI1LTAxIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJzdWIiOiI5MDA4NzE2NSIsImlhdCI6MTYwMDAwMDAwMCwiZXhwIjoxNjAwMDAzNjAwLCJzY29wZSI6InJlYWQ6dXNlciB3cml0ZTpwb3N0In0.signature_placeholder
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2025-01"
}

{
  "iss": "https://auth.example.com",
  "aud": "api.example.com",
  "sub": "90087165",
  "iat": 1600000000,
  "exp": 1600003600,
  "scope": "read:user write:post"
}

Token dostępu w stylu OAuth podpisany kluczem RSA — w header widoczne jest pole kid (key ID), a claim exp pokazuje, że token już wygasł.

Token OIDC ID

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJzdWIiOiIxMTA1MDIyNTExNTU4OTkwNzY2Mzk1IiwiYXpwIjoiY2xpZW50LWlkIiwiYXVkIjoiY2xpZW50LWlkIiwiZW1haWwiOiJhbGljZUBleGFtcGxlLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJpYXQiOjE3MTUwMDAwMDAsImV4cCI6MTk5OTk5OTk5OSwibm9uY2UiOiJhYmMxMjMifQ.signature
{
  "alg": "ES256",
  "typ": "JWT"
}

{
  "iss": "https://accounts.google.com",
  "sub": "110502251155899076639",
  "azp": "client-id",
  "aud": "client-id",
  "email": "alice@example.com",
  "email_verified": true,
  "iat": 1715000000,
  "exp": 1999999999,
  "nonce": "abc123"
}

Token ID OpenID Connect z podpisem ECDSA, claimami zawierającymi e-mail oraz wartością nonce zabezpieczającą przed atakiem powtórzeniowym.

Token z alg:none (niepodpisany)

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZWJ1Zy11c2VyIiwiaWF0IjoxNzE1MDAwMDAwfQ.
{
  "alg": "none",
  "typ": "JWT"
}

{
  "sub": "debug-user",
  "iat": 1715000000
}

Niepodpisany token z alg:none. Akceptowanie takich tokenów na produkcji to klasyczna podatność JWT — alg:none należy zawsze odrzucać po stronie serwera.

Jak używać

  1. 1

    Wklej JWT do zdekodowania

    Wklej pełny JWT — wraz z trzema segmentami oddzielonymi kropkami — do pola wejściowego. Dekoder uruchamia się natychmiast w przeglądarce; nie trzeba klikać żadnego przycisku.

  2. 2

    Odczytaj zdekodowany header, payload i status

    Odczytaj algorytm i typ tokena w zdekodowanym header, claims w payload oraz plakietki wygaśnięcia i czasu wystawienia na górze. Wygasły token jest oznaczony na czerwono.

  3. 3

    Skopiuj zdekodowany wynik

    Użyj przycisku Kopiuj na każdym panelu, aby skopiować JSON header, JSON payload lub surowy signature. Token nigdy nie został nigdzie wysłany — dekodowanie odbyło się lokalnie w przeglądarce.

Common Errors

Akceptowanie alg:none

Niepodpisany JWT może sfabrykować każdy. Nigdy nie zezwalaj na alg:none na produkcji — zawsze przekazuj jawną listę algorytmów do wywołania weryfikującego.

✗ Niepoprawne
jwt.verify(token, secret)  // library default may allow 'none'
✓ Poprawne
jwt.verify(token, secret, { algorithms: ['RS256'] })

Brak claim exp

JWT bez exp żyje wiecznie. Jeśli token kiedykolwiek wycieknie, nie ma naturalnego punktu unieważnienia. Zawsze ustawiaj datę wygaśnięcia odpowiednią do typu tokena.

✗ Niepoprawne
{ "sub": "user_123", "role": "admin" }  // no exp
✓ Poprawne
{ "sub": "user_123", "role": "admin", "exp": 1715003600 }

Przechowywanie sekretów w payload

Payload JWT nie jest szyfrowany — każdy, kto ma token, może go odczytać. Nigdy nie umieszczaj w payload haseł, kluczy API ani pełnych danych osobowych.

✗ Niepoprawne
{ "sub": "user_123", "password": "hunter2" }
✓ Poprawne
{ "sub": "user_123", "role": "admin" }  // payload stays minimal

Typowe zastosowania

Dekodowanie tokenów Authorization Bearer
Dekoduj tokeny JWT z nagłówków Authorization: Bearer, aby zweryfikować claims, audience i datę wygaśnięcia, jakie odbiera backend.
Dekodowanie tokenów OAuth 2.0 i OIDC
Dekoduj tokeny dostępu i tokeny ID zwracane przez serwery autoryzacji (Auth0, Okta, Google, Keycloak) podczas integracji z OAuth 2.0 i OpenID Connect.
Diagnoza wygasłej sesji
Potwierdź w sekundę, czy odrzucony token wygasł, używa nieprawidłowego audience lub ma problem z rozjazdem zegarów.
Kontrola rotacji kluczy
Odczytaj kid (key ID) w header, aby sprawdzić, czy JWKS wystawia tokeny podpisane oczekiwanym kluczem.
Przeglądy bezpieczeństwa
Wychwytuj tokeny podpisane alg:none, brakujące exp lub dane osobowe wyciekające w payload podczas przeglądów kodu i pentestów.
Inspekcja tokenów mikroserwisowych
Dekoduj tokeny komunikacji service-to-service wewnątrz siatki, aby zobaczyć, jakie scope i jaki subject autoryzują wywołanie w dół stosu.

Szczegóły techniczne

Zgodność z RFC 7519
Obsługuje tokeny JWS zgodne z RFC 7519 (JWT), RFC 7515 (JWS) oraz RFC 7518 (JWA) — dekodowanie wspiera wszystkie zarejestrowane algorytmy.
Dekodowanie Base64URL
Korzysta z bezpiecznego dla URL-i alfabetu Base64 (- i _ zamiast + i /) zdefiniowanego w RFC 4648, z parsowaniem tolerującym padding.
Natywne w przeglądarce, zero zależności
Zbudowane na atob, TextDecoder i JSON.parse z przeglądarki — bez bibliotek zewnętrznych, bez wywołań sieciowych, bez telemetrii.

Dobre praktyki

Nie ufaj bez weryfikacji
Dekoder pokazuje claims; nie udowadnia ich. Przed zaufaniem jakiemukolwiek claim należy zawsze zweryfikować signature po stronie serwera kluczem wystawcy.
Odrzucaj alg:none na produkcji
Skonfiguruj bibliotekę JWT z jawną listą dozwolonych algorytmów. Nigdy nie akceptuj alg:none i podchodź podejrzliwie do niezgodności alg przy rotacji kluczy.
Trzymaj payload w ryzach
Umieszczaj w JWT identyfikatory i krótkotrwałe claims; objętościowe dane trzymaj za nieprzezroczystym ID sesji. Duże tokeny obciążają pasmo przy każdym żądaniu.

Najczęściej zadawane pytania

Jak zdekodować token JWT online?
Wystarczy wkleić pełny JWT — wszystkie trzy segmenty oddzielone kropkami (header.payload.signature) — do dekodera powyżej. Dekodowanie odbywa się natychmiast w przeglądarce: header oraz payload są dekodowane z Base64URL do czytelnego JSON, a signature wyświetlany jest jako surowy ciąg znaków. Wiersz statusu pokazuje algorytm podpisu, czas wystawienia oraz datę wygaśnięcia, dzięki czemu wygasły token można rozpoznać na pierwszy rzut oka. Aby zdekodować JWT ręcznie, wystarczy podzielić token po kropkach, zdekodować pierwsze dwa segmenty z Base64URL i sparsować jako JSON — każdy, kto ma token, może odczytać jego claims, ponieważ payload jest zakodowany, ale nieszyfrowany. Dekodera można bezpiecznie używać z produkcyjnymi tokenami, ponieważ żadne dane nie opuszczają urządzenia: brak żądań sieciowych, logowania i śledzenia.
Czym jest JWT (JSON Web Token)?
JSON Web Token (JWT) to zwarty, bezpieczny dla URL-i format poświadczenia, przenoszący claims między dwiema stronami. Zdefiniowany w RFC 7519, składa się z trzech sekcji zakodowanych w Base64URL i połączonych kropkami: header (algorytm i typ tokena), payload (claims — dane o użytkowniku i o samym tokenie) oraz signature (kryptograficzny dowód, że token został wystawiony przez zaufaną stronę). JWT to standardowy sposób reprezentowania tokenów dostępu w OAuth 2.0 oraz tokenów ID w OpenID Connect.
Czy mój token jest bezpieczny w tym dekoderze JWT?
Tak. Całe dekodowanie odbywa się w przeglądarce za pomocą natywnego JavaScriptu (atob i TextDecoder). Token nigdy nie jest wysyłany na serwer, nie jest logowany, nie jest zapisywany ani wykorzystywany do analityki. Nie ma cookies ani śledzenia. Ma to znaczenie, bo JWT może zawierać aktywne tokeny dostępu — wklejenie ich w zdalny debugger byłoby równoznaczne z przekazaniem poświadczenia. Naszego narzędzia można bezpiecznie używać z tokenami produkcyjnymi.
Jak działa dekoder JWT?
Dekoder JWT dzieli token po kropkach na trzy części, dekoduje header i payload z Base64URL, a następnie parsuje je jako JSON. Signature pozostaje nieprzezroczystym ciągiem Base64URL, ponieważ jego weryfikacja wymaga sekretu wystawcy lub klucza publicznego — czego dekoder działający po stronie klienta nie może zrobić bezpiecznie. Oznacza to, że dekodowanie jest natychmiastowe i ujawnia claims, ale signature trzeba zweryfikować po stronie serwera odpowiednim kluczem, zanim cokolwiek wewnątrz uzna się za wiarygodne.
Czy to narzędzie weryfikuje signature JWT?
Nie i celowo tego nie robi. Weryfikacja signature wymaga sekretu wystawcy (dla HMAC) lub klucza publicznego (dla RSA/ECDSA/EdDSA), które nigdy nie powinny być wklejane do publicznego narzędzia webowego. Weryfikacja musi odbywać się na serwerze, w warstwie middleware uwierzytelniania lub wewnątrz SDK, który ma dostęp do endpointu JWKS. Ten dekoder służy do podglądu tego, co token deklaruje — nie sugeruje, że token jest autentyczny ani że nie został zmodyfikowany.
Czym są iat, exp, nbf, iss, aud, sub i jti?
To zarejestrowane claims z RFC 7519. iat (issued at) to timestamp Unix oznaczający moment utworzenia tokena. exp (expiration) to chwila, w której token przestaje być ważny — to narzędzie zamienia tę wartość na czytelną datę i oznacza token jako wygasły, jeśli exp znajduje się w przeszłości. nbf (not before) to najwcześniejszy moment, w którym token może zostać użyty. iss (issuer) wskazuje, kto utworzył token. aud (audience) wskazuje docelowego odbiorcę. sub (subject) identyfikuje principala — zwykle ID użytkownika. jti to unikalny identyfikator tokena chroniący przed atakiem powtórzeniowym. Obok nich w payload występują claims aplikacyjne (role, scope, email, name).
Mój JWT wygasł — dlaczego dekoder nadal go dekoduje?
Dekodowanie to nie to samo co walidacja. Dekoder JWT odczytuje treść niezależnie od daty wygaśnięcia, dzięki czemu można obejrzeć wygasły lub w inny sposób nieprawidłowy token i zdiagnozować, dlaczego został odrzucony. Plakietka „Wygasły” w tym narzędziu porównuje claim exp z lokalnym zegarem i oznacza tokeny, dla których exp znajduje się w przeszłości. Prawdziwy serwer uwierzytelniania odrzuciłby taki token z marszu — ale dekoder, który nie pokazywałby wygasłych tokenów, byłby bezużyteczny w debugowaniu.
Jaka jest różnica między JWT, JWS i JWE?
JWT to ogólne pojęcie — obiekt JSON zakodowany jako zwarty token. JWS (RFC 7515) to podpisany JWT: payload jest czytelny dla każdego, kto go zdekoduje, a signature dowodzi, że nie został zmodyfikowany. To zdecydowanie najczęściej spotykany rodzaj JWT. JWE (RFC 7516) to zaszyfrowany JWT: sam payload to szyfrogram i nie da się go zdekodować bez klucza deszyfrującego. To narzędzie dekoduje tokeny JWS. Token JWE zostanie zdekodowany jedynie do header — zaszyfrowany payload bez klucza pozostanie nieczytelny.
Dlaczego alg:none jest niebezpieczny?
JWT z alg:none nie ma signature — każdy może go skonstruować, podszywając się pod dowolnego użytkownika. Wczesne biblioteki JWT akceptowały alg:none domyślnie, co doprowadziło do dobrze znanej klasy obejść uwierzytelniania, w których atakujący usuwał signature, ustawiał alg na none i fabrykował token administratora. Każda dojrzała biblioteka JWT odrzuca dziś alg:none, jeśli nie zostanie to jawnie dozwolone, i nigdy nie należy akceptować takiego tokena dla żądań uwierzytelnionych. Ten dekoder pokaże token alg:none, bo podgląd takiego przypadku w trakcie debugowania jest uzasadniony — ale każdy taki token otrzymany na produkcji należy traktować jako wrogi.
Jakie algorytmy obsługuje ten dekoder JWT?
Dekodowanie header i payload działa dla każdego algorytmu, ponieważ wymaga jedynie Base64URL i parsowania JSON — jest niezależne od algorytmu. Narzędzie poprawnie odczytuje tokeny podpisane HS256, HS384, HS512 (HMAC), RS256, RS384, RS512 (RSA + SHA), PS256, PS384, PS512 (RSA-PSS), ES256, ES384, ES512 (ECDSA), EdDSA (Ed25519/Ed448) oraz tokeny niepodpisane (alg:none). Tylko weryfikacja signature jest specyficzna dla algorytmu, a tego to narzędzie nie wykonuje.
Czy przechowywać JWT w localStorage czy w cookies?
Lepiej wybrać cookies HttpOnly, Secure, SameSite=Strict dla tokenów sesyjnych. Token w localStorage jest dostępny dla każdego JavaScriptu działającego na stronie, więc jedna podatność XSS oznacza wyciek wszystkich aktywnych sesji. Cookies HttpOnly są niewidoczne dla JavaScriptu, co ogranicza skutki XSS do tego, co atakujący może zrobić w obrębie żywej strony — nie do skradzionego tokena, którego mógłby używać przez wiele dni. Jeśli musisz korzystać z localStorage (na przykład w aplikacjach cross-domain), utrzymuj krótki czas życia tokenów dostępu (minuty, nie godziny) i używaj osobnego refresh tokena w cookie HttpOnly.
Jak zdekodować JWT w Node.js, Pythonie lub Go?
Node.js: jsonwebtoken.decode(token) do samego odczytu, jsonwebtoken.verify(token, key) do weryfikacji. Python: PyJWT.decode(token, options={'verify_signature': False}) do odczytu, do weryfikacji należy przekazać klucz. Go: jwt.ParseUnverified(token, claims) do samego odczytu, jwt.Parse(token, keyFunc) do weryfikacji. W żadnym języku nie należy weryfikować z options={'verify_signature': False} w kodzie produkcyjnym — to jest właśnie to, co celowo robi to narzędzie webowe na potrzeby debugowania, i jest bezpieczne tylko wtedy, gdy się ogląda, a nie uwierzytelnia.
Jaki jest maksymalny rozmiar JWT?
Standard JWT nie nakłada twardego limitu, ale nagłówki w większości serwerów WWW domyślnie kończą się około 8 KB. Warto utrzymywać tokeny poniżej 4 KB, aby wygodnie mieściły się w nagłówkach Authorization i w cookies. Jeśli token jest większy, prawdopodobnie w payload znalazło się zbyt wiele claims — lepiej przenieść objętościowe dane za nieprzezroczyste ID sesji i pobierać je z backendu, gdy są potrzebne. Rozdęte JWT również drożej kosztują, bo są wysyłane przy każdym wywołaniu API.
Wkleiłem token i otrzymałem komunikat „Nieprawidłowy format JWT” — co się stało?
Poprawny JWT ma dokładnie trzy części oddzielone kropkami: header.payload.signature. Najczęstsze przyczyny: (1) skopiowano przypadkiem tylko segment payload, (2) w środku znalazły się białe znaki lub znaki nowej linii, (3) token został skrócony w transmisji (typowe przy zawijaniu w terminalu), (4) token to JWE w formacie header.encryptedKey.iv.ciphertext.tag (pięć segmentów) lub (5) token został zakodowany w URL i trzeba go najpierw zdekodować z URL. Sprawdź surową wartość zwróconą przez API — większość edytorów pokazuje znaki niewidoczne po najechaniu kursorem.
Czy można zdekodować JWT bez klucza tajnego?
Tak — header i payload są zakodowane w Base64URL, a nie zaszyfrowane. Każdy, kto ma token, może odczytać jego claims bez żadnego klucza. Tak zostało to zaprojektowane: payload ma być czytelny, aby odbiorca mógł podejmować na jego podstawie decyzje autoryzacyjne. Sekret lub klucz publiczny jest potrzebny wyłącznie do zweryfikowania, że token nie został zmodyfikowany. Właśnie dlatego nigdy nie należy umieszczać w payload JWT danych wrażliwych (haseł, kluczy prywatnych, danych osobowych wykraczających poza to, co odbiorca już zna).
Mój JWT działa w Postmanie, ale backend go odrzuca — jak to zdebugować?
Zdekoduj token tutaj i sprawdź: (1) exp — czy znajduje się w przyszłości względem zegara serwera? Rozjazd zegarów to częsty winowajca. (2) iss / aud — czy dokładnie zgadzają się z tym, czego oczekuje backend? Niezgodność aud to najczęstszy fałszywy negatyw. (3) alg — czy kod weryfikujący dopuszcza ten algorytm? Token HS256 nie przejdzie w bibliotece skonfigurowanej tylko na RS256. (4) kid — jeśli korzystasz z rotacji kluczy, czy key ID z header występuje w Twoim JWKS? (5) signature — czy wkleiłeś właściwy sekret lub klucz publiczny? Ten dekoder pokazuje punkty (1), (2), (3) i (4) w widoku header oraz payload, więc można je szybko wyeliminować.

Powiązane narzędzia

Zobacz wszystkie narzędzia →