Декодируйте любой 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 пользователя, e-mail, scopes, а иногда и эквивалент сессионных cookie — именно те данные, которые нельзя вставлять на чужой сервер. Декодер iKit работает как JavaScript, уже загруженный в вашей вкладке. Это можно проверить в DevTools → Network: ни fetch, ни XHR, ни beacon при декодировании или проверке.
Для токенов HS256/384/512 введите секрет подписи, чтобы проверить её локально. Для RS256/ES256 (RSA/ECDSA) используйте серверную библиотеку — для проверки по открытому ключу нужен PEM-файл, который мы здесь не принимаем.
Для HS256 нужно минимум 32 байта (256 бит) для настоящей криптографической стойкости. Для тестов подойдёт что угодно, но в продакшене используйте длинный случайный секрет.
Самый быстрый способ отладить JWT — без загрузки, без регистрации, без посредников между вами и токеном.
Вставьте JWT и увидите декодированный заголовок, полезную нагрузку и подпись рядом. Стандартные claims (iss, sub, aud, exp, iat) преобразуются во временные метки и подписываются.
Для токенов HS256/384/512 введите секрет, чтобы проверить подпись через Web Crypto API браузера. Секрет не покидает вкладку.
Переключитесь в режим Encode, отредактируйте заголовок и полезную нагрузку как JSON, выберите алгоритм, введите секрет — и мгновенно получите подписанный токен.
Полезная нагрузка JWT содержит ID пользователей, e-mail, иногда scopes — никогда не вставляйте её в серверные инструменты. Декодер iKit работает как JavaScript в вашем браузере. Это можно проверить в DevTools → Network.
Стандартные claims, такие как exp, nbf, iat, выделяются с понятными датами и явным значком ИСТЁК / действителен — вы сразу видите, годен ли токен.
Построено на нативном Web Crypto API браузера и парсере JSON — те же алгоритмы, что в OpenSSL, libjwt, jose. Поведение совпадает с любой современной библиотекой JWT.
JWT — это три сегмента JSON в кодировке base64url, разделённые точками, и не более того.
JWT выглядит как aaa.bbb.ccc. Мы разделяем строку по двум точкам и получаем закодированные заголовок, полезную нагрузку и подпись. Если получается не ровно три части — токен повреждён.
Заголовок и полезная нагрузка — это JSON в UTF-8, закодированный в base64url. Base64URL = Base64 с символами -/_ вместо +//= и без выравнивания. Мы выполняем atob после обратной замены символов, затем JSON.parse полученной строки.
Заголовок сообщает алгоритм (alg: HS256, RS256 и т. д.) и тип. Полезная нагрузка содержит claims — стандартные (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, чтобы увидеть, какие claims действительно получает ваше приложение — какой ID пользователя, какие scopes, когда истекает токен.
API отклоняет запрос? Декодируйте токен и проверьте: не истёк ли он (exp в прошлом)? Совпадает ли claim audience (aud) с тем, что ожидает API? Тот ли это издатель (iss)?
Stripe, GitHub Apps, Slack отправляют полезные нагрузки вебхуков, подписанные как JWT. Получив такой запрос, вставьте его в режим Decode вместе с общим секретом, чтобы убедиться, что запрос действительно пришёл от них.
Нужен свежий подписанный JWT для интеграционного теста? Переключитесь в режим Encode, отредактируйте полезную нагрузку (свой ID пользователя, своё время истечения), выберите HS256 + ваш тестовый секрет — и получите токен за миллисекунды. Без обращения к бэкенду.
JWT часто содержит ID пользователя, e-mail, scopes, а иногда и эквивалент сессионных 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, а на нашем домене нет сторонних трекеров). Мы добавили чёткий значок ИСТЁК / действителен для claim exp, структурированные пояснения к claims (iat / nbf / iss / sub / aud / jti как читаемые строки) и кнопку «скопировать всё декодированное», которая выдаёт полный структурированный вывод для вставки в баг-репорт.