Декодуйте будь-який JSON Web Token, щоб побачити його заголовок, корисне навантаження та підпис, або підпишіть новий за допомогою HS256/384/512. Перевіряє HMAC-підписи локально. 100% у вашому браузері.
Декодуйте будь-який JSON Web Token, щоб побачити його заголовок, корисне навантаження та підпис, або підпишіть новий за допомогою HS256/384/512. Перевіряє HMAC-підписи локально. 100% у вашому браузері.
Ні. Увесь інструмент — це JavaScript усередині цієї сторінки. Ви вставляєте токен, декодування відбувається у вашому браузері, байти ніколи не залишають вкладку. Відкрийте DevTools → Network і подивіться — під час декодування чи перевірки запити не надсилаються. Тому безпечно вставляти реальні клієнтські або продакшн-токени.
Він доводить, що токен підписав той, хто володіє секретом (HMAC) або приватним ключем (RSA/ECDSA). Він НЕ шифрує корисне навантаження — заголовок і корисне навантаження це звичайний JSON у base64url, будь-хто з токеном може їх прочитати. Підпис лише запобігає підробці: якщо змінити хоча б один байт корисного навантаження, підпис більше не збігатиметься.
JWT часто містить ID користувача, електронну пошту, скоупи, а інколи й аналог сесійних cookie — саме ті дані, які НЕ можна вставляти у чужий сервер. Декодер iKit працює як JavaScript, уже завантажений у вашій вкладці браузера. Це можна перевірити в DevTools → Network: жодного fetch, XHR чи beacon під час декодування або перевірки.
Для токенів HS256/384/512 введіть секрет підпису, щоб перевірити підпис локально. Для RS256/ES256 (RSA/ECDSA) використовуйте серверну бібліотеку — для перевірки відкритим ключем потрібен PEM-файл, який ми тут не приймаємо.
HS256 потребує щонайменше 32 байти (256 біт) для справжньої криптографічної стійкості. Для тестів підійде будь-що, але у продакшені слід використовувати довгий випадковий секрет.
Найшвидший спосіб налагодити JWT — без завантажень, без реєстрації, без посередників між вами та вашим токеном.
Вставте JWT та одночасно побачте декодовані заголовок, корисне навантаження і підпис. Стандартні клейми (iss, sub, aud, exp, iat) отримують позначки часу та підписи.
Для токенів HS256/384/512 введіть секрет, щоб перевірити підпис за допомогою браузерного API Web Crypto. Секрет ніколи не залишає вашу вкладку.
Перейдіть у режим Encode, відредагуйте заголовок і корисне навантаження як JSON, оберіть алгоритм, введіть секрет — і миттєво отримайте підписаний токен.
Корисні навантаження JWT містять ідентифікатори користувачів, електронні пошти, інколи скоупи — ніколи не вставляйте їх у серверні інструменти. Декодер iKit працює як JavaScript у вашому браузері. Це можна перевірити в DevTools → Network.
Стандартні клейми, як-от exp, nbf, iat, виділяються зрозумілими датами та чіткими позначками EXPIRED / valid, тож ви одразу бачите, чи токен ще дійсний.
Побудовано на нативному браузерному API Web Crypto та парсері JSON — ті самі алгоритми, що й у OpenSSL, libjwt, jose. Поведінка відповідає кожній сучасній бібліотеці JWT.
JWT — це три сегменти JSON у base64url, розділені крапками — і все.
JWT виглядає як aaa.bbb.ccc. Ми розділяємо за двома буквальними крапками, отримуючи закодовані заголовок, корисне навантаження та підпис. Якщо частин не рівно три, токен пошкоджений.
Заголовок і корисне навантаження — це JSON у UTF-8, закодований base64url. Base64URL = Base64 з -/_ замість +//= та без доповнення. Ми робимо atob після зворотної заміни символів, потім JSON.parse результату.
Заголовок повідомляє нам алгоритм (alg: HS256, RS256 тощо) і тип. Корисне навантаження містить клейми — стандартні (iss, sub, aud, exp, iat, nbf, jti) плюс будь-які власні поля. Кожне ми показуємо в підписаному розділі.
Для HS256/384/512 ми перераховуємо HMAC від header.payload з введеним вами секретом і порівнюємо з підписом у третьому сегменті. Те саме, що HMAC(SHA-256, secret, signing_input), закодоване base64url. Збіг = підпис дійсний.
Реальні ситуації, коли вам знадобиться декодер JWT.
Auth0, Firebase, Keycloak, AWS Cognito повертають JWT після входу. Вставте access_token, щоб побачити, які саме клейми отримує ваш застосунок — який ID користувача, які скоупи, коли спливає термін дії?
API відхиляє ваш запит? Декодуйте токен, щоб перевірити: чи не протерміновано його (exp у минулому)? Чи клейм аудиторії (aud) відповідає очікуванням API? Чи видавець (iss) — правильний тенант?
Stripe, GitHub Apps, Slack надсилають корисні навантаження вебхуків, підписані як JWT. Отримавши такий, вставте його у режим Decode разом зі спільним секретом, щоб переконатися, що запит дійсно надійшов від них.
Потрібен свіжий підписаний JWT для інтеграційного тесту? Перейдіть у режим Encode, відредагуйте корисне навантаження (власний ID користувача, власний термін дії), оберіть HS256 + ваш тестовий секрет, отримайте токен за мілісекунди. Без походів на бекенд.
JWT часто містить ID користувача, електронну пошту, скоупи, а інколи й аналог сесійних cookie — саме ті дані, які НЕ можна вставляти у чужий сервер. Декодер iKit працює як JavaScript, уже завантажений у вашій вкладці браузера. Це можна перевірити в DevTools → Network: жодного fetch, XHR чи beacon під час декодування або перевірки.
Детальні посібники та порівняння інструментів з блогу iKit.
JWT segments are base64url-encoded JSON — understand the encoding before you debug a token.
JWT signatures are HMAC-SHA hashes — the same family of cryptographic hashes used to verify file integrity.
Ні. Увесь інструмент — це JavaScript усередині цієї сторінки. Ви вставляєте токен, декодування відбувається у вашому браузері, байти ніколи не залишають вкладку. Відкрийте DevTools → Network і подивіться — під час декодування чи перевірки запити не надсилаються. Тому безпечно вставляти реальні клієнтські або продакшн-токени.
Він доводить, що токен підписав той, хто володіє секретом (HMAC) або приватним ключем (RSA/ECDSA). Він НЕ шифрує корисне навантаження — заголовок і корисне навантаження це звичайний JSON у base64url, будь-хто з токеном може їх прочитати. Підпис лише запобігає підробці: якщо змінити хоча б один байт корисного навантаження, підпис більше не збігатиметься.
Три типові причини: (1) неправильний секрет — секрети JWT чутливі до регістру, і будь-яка розбіжність у пробілах ламає перевірку. (2) Невідповідність алгоритму — заголовок каже HS256, але секрет спочатку використовувався з HS512. (3) Токен було змінено після підпису — навіть один байт ламає підпис. Перевірте, чи header.alg відповідає очікуваному.
Наразі iKit підтримує лише перевірку HMAC (HS256/384/512). RS256 та ES256 використовують криптографію з відкритим ключем — для перевірки потрібен публічний ключ видавця у форматі PEM, що потребує складнішого інтерфейсу. Поки що декодування все одно працює (заголовок/корисне навантаження/підпис відображаються коректно), але кнопка Verify повідомить, що це не підтримується. Перевірку RSA/ECDSA заплановано.
Та сама ідея, інші налаштування за замовчуванням. Декодер iKit працює повністю у вашому браузері (jwt.io теж, але код iKit відкритий через view-source, і наш домен не має сторонніх трекерів). Ми додаємо чітку позначку EXPIRED / valid для клейма exp, структуровані примітки до клеймів (iat / nbf / iss / sub / aud / jti як читабельні рядки) та кнопку "скопіювати все декодоване", яка дає повний структурований вивід для вставлення у баг-репорт.