Encoders & Utilities

JWT Decoder

Декодує header і payload JWT просто у браузері.

JWT token Paste a JWT — we will split it into header, payload, and signature.

Про цей інструмент

JSON Web Token (RFC 7519) — це три Base64url-encoded сегменти, з'єднані крапками: header, payload і signature. JWT Decoder розділяє токен, декодує перші два сегменти в JSON, форматує їх і обчислює time-related claims (iat, exp, nbf) як human-readable timestamps. Стандартні registered-claims (iss, sub, aud, jti) маркуються зі своїм значенням. Декодування йде повністю у вашому браузері — ваш токен ніколи не покидає сторінку.

Header каже вам signing algorithm (alg: HS256, RS256, ES256 тощо) і опційний kid (key ID). Payload містить application-claims — user ID, roles, expiry. Signature показано як Base64-blob; ми свідомо не верифікуємо його на цій сторінці, бо верифікація потребує secret видавця або public key, які ніколи не варто вставляти в third-party-інструмент. Токен трактується лише як data.

Коли використовувати цей інструмент

Читання токена з вашого сервісу. Інспектуйте, які claims ви реально emit-ите — швидко помітьте відсутні поля, неправильні audiences або несподівані defaults.
Дебаг «401 Unauthorized»-відповідей. Перевірте expiry, issuer, audience і scope проти того, що очікує сервер.
Верифікація third-party інтеграції. Коли OAuth-провайдер віддає вам ID-token, декодуйте payload, щоб побачити, які user-claims вони пакують.
Виявлення algorithm confusion. Якщо alg = none або несподівано різниться між токенами, ваша auth-бібліотека ймовірно misconfigured.

Чому ми не валідуємо підпис

Верифікація JWT-підпису потребує secret (для HMAC-алгоритмів) або public key видавця (для RSA/ECDSA). Вставляти будь-що з цього в web-tool — security-помилка: secret скомпрометує кожен виданий токен; public key, хоч і менш чутливий, теж може бути приватним. Декодер підтверджує структуру і виявляє claims; для реальної верифікації використовуйте SDK, що йде з вашою auth-бібліотекою (jsonwebtoken, pyjwt, jose) всередині свого коду.

Часті запитання

Чи безпечно вставляти мій JWT сюди?

Декодування йде повністю в JavaScript у вашому браузері — жодного мережевого виклику не робиться, жодного логування server-side. Однак JWT у продакшні треба трактувати як credentials: не вставляйте long-lived токен від сервісу, який ви не контролюєте, у жоден third-party-інструмент, включно з нашим. Для dev/staging-токенів або експайрнутих — тут декодувати ОК.

Чому signature показано, але не верифіковано?

Бо верифікація потребує signing key, а вставка signing key у web-tool була б серйозною помилкою. Signature показано як Base64, щоб ви бачили, що він існує і має правильну довжину для алгоритму, але фактична валідація проти HMAC-secret (HS256) або public key (RS256/ES256) має жити всередині вашого додатка, а не в browser-tool.

Що означає «alg: none»?

Unsigned JWT. Header явно каже, що алгоритм не застосовано, тож signature-сегмент порожній. alg: none існує в специфікації, але ніколи не має з'являтися в продакшні — це коренева причина знаменитої «JWT none-algorithm»-вразливості, де бібліотека приймає none як валідний. Якщо ви бачите це в реальному токені реального сервісу — це серйозний баг.

Яка різниця між exp, iat і nbf?

iat (issued-at) — коли токен створено. nbf (not-before) — найраніший час, коли токен можна використовувати — зазвичай дорівнює iat, але може бути в майбутньому для відкладеної активації. exp (expiration) — коли токен перестає бути валідним. Усі три — Unix timestamps у секундах. Добре поведений верифікатор перевіряє nbf ≤ now ≤ exp на кожному запиті.