Кодування
JWT Encoder/Decoder
Кодування та декодування JWT-токена — заголовок, корисне навантаження, підпис HMAC і стандартні поля.
Підписані приклади (усі, крім none) потребують HTTPS — зараз сторінка відкрита без HTTPS.
Для RS/PS/ES ключ генерується автоматично та тимчасово — лише для демонстрації, повторно скористатись ним не можна.
Підписані приклади (усі, крім none) потребують HTTPS — зараз сторінка відкрита без HTTPS.
Claims
JWT (JSON Web Token) — це компактний формат для передачі підписаних даних, який складається з трьох частин, розділених крапкою: заголовка (header), корисного навантаження (payload) і підпису (signature). Інструмент декодує будь-який JWT і показує всі три частини, а також дозволяє зібрати новий токен із підписом HMAC.
Декодування не перевіряє валідність підпису — щоб побачити вміст токена, секретний ключ не потрібен. Перевірка підпису потрібна лише тоді, коли ви довіряєте токену як справжньому.
Як користуватися
- Декодування: вставте JWT — інструмент розбере його на header, payload і підпис та підсвітить стандартні поля (exp, iat, sub тощо).
- Кодування: заповніть header і payload, вкажіть секрет — отримаєте готовий підписаний токен HMAC (HS256/HS384/HS512).
- Перевірка терміну дії: поле exp показується як звичайна дата, тому одразу видно, чи не протермінований токен.
Типові сценарії
- Діагностика проблем автентифікації — швидко подивитися, що саме лежить у токені з запиту.
- Перевірка, які claims (ролі, дозволи, термін дії) видає бекенд.
- Генерація тестового токена для локальної розробки без запуску сервера авторизації.
Що варто памʼятати
JWT не зашифрований, а лише закодований у Base64URL — будь-хто може прочитати payload. Не кладіть туди паролі чи інші секрети.
Підпис захищає від підробки даних, але не від їх перегляду. Для конфіденційності потрібне додаткове шифрування (JWE) або HTTPS-транспорт.
Стаття про цей інструмент: JWT: структура токена та що означає "декодувати" JWT
Часті запитання
Чи перевіряє декодування підпис токена?
Ні. Декодування без секрету/ключа лише розбирає Header і Payload — це просто Base64URL-дані, доступні будь-кому. Це не доводить, що токен справжній і не був підроблений; для перевірки автентичності потрібен правильний секрет або публічний ключ.
Чи безпечно вставляти реальний JWT або секрет у цей інструмент?
Так — усе кодування, декодування й підписування виконується локально у вашому браузері. Ні токен, ні секрет нікуди не надсилаються.
Що означають claims exp, nbf та iat?
Це стандартні тимчасові поля payload: iat — час видачі токена, nbf — момент, з якого токен стає дійсним, exp — момент, після якого токен вважається простроченим. Усі три задаються як Unix-час у секундах.
Що таке атака з підміною алгоритму на "none"?
Якщо бекенд наївно довіряє полю alg із заголовка токена, зловмисник може замінити його на none, прибрати підпис — і токен з довільними даними пройде перевірку. Надійні бібліотеки вимагають явно задавати очікуваний алгоритм при верифікації.
Чому не варто зберігати JWT у localStorage для чутливих сесій?
localStorage доступний будь-якому JavaScript-коду на сторінці, тому вразливий до XSS — шкідливий скрипт може вкрасти токен. Для сесійних токенів безпечніше використовувати httpOnly-cookie, недоступні для JavaScript.