JWT Decoder

Декодування та інспекція JSON Web Token

Спробувати приклад

JWT-токен

Працює локально · Безпечно вставляти секрети
Також спробуйте:JWT Encoder

Що таке JWT (JSON Web Token)?

JSON Web Token (JWT) — це компактний, URL-безпечний формат токена, визначений у RFC 7519. Він кодує набір claims як об'єкт JSON, а потім підписує — і за потреби шифрує — його, щоб одержувач міг переконатись у тому, що дані не були змінені. JWT є де-факто стандартом для автентифікації без стану в REST API, системах єдиного входу та авторизації мікросервісів.

Структура JWT: Header · Payload · Signature

Кожен JWT складається з трьох сегментів у кодуванні base64url, розділених крапками. Header і Payload — це звичайний JSON, доступний для читання будь-ким, тоді як Signature — криптографічне значення, яке можна перевірити лише правильним ключем.

Закодований токен

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HeaderPayloadSignature
Header
json
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
json
{
  "sub":  "user123",
  "name": "Alice",
  "role": "admin",
  "iat":  1717200000,
  "exp":  1717203600
}

Навіщо використовувати декодер JWT?

Необроблені JWT виглядають як випадковий текст. Цей інструмент миттєво відображає Header і Payload у вигляді відформатованого JSON, щоб ви могли перевіряти claims, переглядати терміни дії та аналізувати вибір алгоритмів без написання жодного рядка коду.

🔍
Миттєва перевірка claims
Переглядайте кожен claim у Payload — sub, iss, aud, exp, власні ролі, дозволи — відформатований і зручний для читання одним кліком.
🔓
Секретний ключ не потрібен
Header і Payload є загальнодоступними; лише Signature потребує секрету. Цей інструмент декодує обидва без вашого ключа підпису.
⏱️
Аналіз термінів дії та міток часу
Unix-мітки часу (exp, iat, nbf) автоматично перетворюються на зрозумілі дати, щоб ви одразу бачили, чи термін дії токена минув.
🔒
Працює повністю у браузері
Все обробляється локально — жодні дані токена не надсилаються на будь-який сервер. Безпечно використовувати з токенами продукційного середовища під час налагодження.

Довідник стандартних claims JWT

RFC 7519 визначає сім зареєстрованих імен claims. Вони не є обов'язковими, але їхнє використання настійно рекомендується для сумісності. Ви можете додавати будь-які власні claims до Payload.

ClaimОписТип
issВидавецьВизначає, хто видав токен — наприклад, URL вашого сервера автентифікації або назва застосунку.string
subСуб'єктВизначає суб'єкт, якому присвячений JWT — зазвичай ID користувача або сервісний обліковий запис.string
audАудиторіяВизначає передбачуваних одержувачів. Сторона-одержувач повинна перевірити, що це відповідає її ідентифікатору.string | string[]
expЧас закінчення діїUnix-мітка часу, після якої токен не повинен прийматися. Завжди встановлюйте це, щоб обмежити шкоду від викраденого токена.number
nbfНе раніше ніжUnix-мітка часу, до якої токен не повинен прийматися. Корисно для планування токенів із майбутньою датою.number
iatВидано оUnix-мітка часу, коли токен був виданий. Використовується для обчислення віку токена.number
jtiJWT IDУнікальний ідентифікатор токена. Дозволяє відкликання шляхом зберігання та перевірки використаних значень JTI на стороні сервера.string

Алгоритми підпису JWT

Claim заголовка alg оголошує, яким алгоритмом підписаний токен. Вибір впливає на безпеку, продуктивність і можливість сторонніх сервісів перевіряти токени без приватного ключа.

АлгоритмСімействоТип ключаПримітки
HS256HMACSymmetricНайпоширеніший. Спільний секрет — будь-хто з секретом може підписувати та перевіряти.
HS384HMACSymmetricНадійніший варіант HMAC; помірне навантаження на продуктивність.
HS512HMACSymmetricНайнадійніший варіант HMAC.
RS256RSAAsymmetricНайбільш використовуваний асиметричний алгоритм (Google, Auth0, Okta). Публічний ключ перевіряє без приватного.
RS384RSAAsymmetricВаріант RS із вищим рівнем безпеки.
RS512RSAAsymmetricНайнадійніший варіант RS.
ES256ECDSAAsymmetricЕліптична крива — коротші підписи, ніж у RSA; популярний на мобільних пристроях та IoT.
PS256RSA-PSSAsymmetricRSA-PSS: сучасніший і безпечніший, ніж RS256 на основі PKCS1v1.5.
noneБез підпису — критично небезпечно. Ніколи не приймайте токени з alg: none у продакшені.

Міркування безпеки

Декодування JWT завжди є безпечним. Довіряти JWT без належної перевірки підпису — ні. Пам'ятайте ці правила щоразу, коли використовуєте токени у своєму застосунку.

Завжди безпечно
  • Декодувати та перевіряти JWT в інструментах розробника або цьому інструменті
  • Використовувати exp, iat і nbf для розуміння терміну дії токена
  • Журналювати claims Payload для налагодження (уникати конфіденційних персональних даних)
  • Читати заголовок alg, щоб зрозуміти, як підписаний токен
Ніколи не робіть це
  • Довіряти claims у Payload без перевірки підпису на стороні сервера
  • Приймати токени з alg: none — це означає повну відсутність підпису
  • Зберігати токени доступу в localStorage у застосунках із підвищеними вимогами безпеки (використовуйте cookie httpOnly)
  • Встановлювати exp далеко в майбутньому для токенів із конфіденційними дозволами

Поширені випадки використання

Налагодження процесів автентифікації
Вставте токен із вкладки мережі браузера, щоб перевірити claims, вбудовані ролі та термін дії без змін у продакшен-коді.
Перевірка токенів сторонніх сервісів
Швидко читайте токени від Google, Auth0, Okta або Azure AD, щоб побачити, які claims включає ваш провайдер, і порівняти їх із очікуваною схемою.
Розробка та тестування API
При написанні або тестуванні API-ендпоінтів декодуйте заголовок авторизації, щоб підтвердити, що ваша логіка генерації токенів правильно встановлює значення sub, aud і scope.
Авторизація мікросервісів
У сервісних мережах кожен сервіс перевіряє JWT від upstream-викликача. Декодуйте токени, щоб відстежити, який сервіс видав токен і які дозволи він заявляє.
Підтримка та реагування на інциденти
Коли користувач повідомляє про помилку автентифікації, декодуйте його токен, щоб перевірити, чи він не закінчився, чи правильна аудиторія та чи не відсутній обов'язковий claim.
Аудит безпеки
Проводьте аудит використання JWT у сервісах, перевіряючи вибір алгоритмів, вікна закінчення терміну дії та чи зберігаються конфіденційні дані у незашифрованому Payload.

Декодування JWT у коді

Header і Payload закодовані у base64url — просто зверніть кодування. Base64url замінює + на - і / на _, та опускає набивку =. Лише Signature потребує секретного ключа.

JavaScript (browser)
function decodeJWT(token) {
  const [, payload] = token.split('.')
  const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
  return JSON.parse(json)
}
Node.js
const [, payload] = token.split('.')
const decoded = JSON.parse(
  Buffer.from(payload, 'base64url').toString()
)
Python
import base64, json

def decode_jwt(token):
    payload = token.split('.')[1]
    padding = '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload + padding))
CLI (bash + jq)
TOKEN="eyJhbGc..."
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .

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

Чи можна декодувати JWT без секретного ключа?
Так. Header і Payload JWT — це просто JSON у кодуванні base64url, а не зашифровані дані. Будь-хто може їх декодувати та прочитати. Секрет (або приватний ключ для алгоритмів RS/ES) потрібен лише для перевірки підпису, що підтверджує незмінність токена.
Чи означає декодування JWT, що підпис перевірено?
Ні. Декодування лише зчитує claims. Верифікація — це окремий крок, який перевіряє криптографічний підпис правильним ключем. Завжди перевіряйте підпис перед тим, як довіряти claims у своєму застосунку.
У чому різниця між HS256 і RS256?
HS256 використовує єдиний симетричний секрет, спільний між видавцем і верифікатором — будь-хто з секретом може створювати та перевіряти токени. RS256 використовує асиметричну пару ключів: приватний ключ підписує, публічний перевіряє. З RS256 можна поширювати публічний ключ, щоб зовнішні сервіси могли перевіряти токени без можливості їх підробки.
Чому декодування base64 іноді не вдається?
JWT використовують кодування base64url, яке замінює + на - і / на _, та опускає символи набивки =. Стандартні декодери base64 вимагають + і / і можуть потребувати набивки. Додайте набивку (до кратного 4 за допомогою =) і замініть символи перед ручним декодуванням.
Чи безпечно вставляти продакшен JWT у цей інструмент?
Так — цей інструмент працює повністю у вашому браузері та не надсилає жодних даних на жодний сервер. Однак зверніть увагу, хто може бачити ваш екран або історію браузера. Для особливо чутливих токенів декодуйте їх локально у терміналі.
Що означає alg: none і чи це небезпечно?
alg: none означає, що токен не має криптографічного підпису — будь-хто може створити токен із довільними claims і встановити alg на none. Деякі ранні бібліотеки JWT приймали такі токени, що призводило до критичної вразливості. Безпечна бібліотека JWT завжди відхиляє токени з alg: none, якщо явно не налаштовано інакше. Ніколи не вимикайте цю перевірку.