§

Вставьте ваш JWT

И разбор, и проверка подписи выполняются локально. Никакая информация о токене не отправляется на сервер.
§

Заголовок

json
§

Полезная нагрузка

json
§

Проверить подпись

Введите секрет, чтобы проверить подпись.

JWT — стандарт сессий в большинстве российских OAuth-flow. ЕСИА на портале Госуслуги выдаёт ID-токены в формате JWT с claim-полями для ИНН и СНИЛС; Сбер ID, Яндекс ID, VK ID и Тинькофф ID следуют той же схеме при логине на сторонних сайтах через OpenID Connect. Платформа 1С-Битрикс24 авторизует REST-вызовы по JWT, а корпоративные SSO в Сбере, Альфа-Банке и Тинькофф используют HS256/RS256 для подписи. Когда токен Yandex Cloud IAM показывает 403 на API Compute Cloud, единственный быстрый способ понять причину — декодировать exp, sub и iss во вкладке, не отправляя боевой токен внешнему отладчику. Это особенно важно с учётом требований ФСТЭК и ФСБ к работе с криптографическим материалом.

// Похожие инструменты

./base64-decoder
Декодер Base64
Изучайте сегменты заголовка и полезной нагрузки, закодированные в base64url, вне оболочки JWT.
→
./url-decoder
Декодер URL
Извлекайте JWT из процентно-кодированных строк запроса и URL-адресов перенаправления.
→
./json-formatter
Форматировщик JSON
Красиво печатайте и проверяйте декодированную полезную нагрузку как отдельный JSON.
→
./
Все инструменты
Просмотрите полный набор онлайн-инструментов Ultim8Soft.
→

Что такое JSON Web Token?

JSON Web Token (JWT) — это компактный, безопасный для URL контейнер для небольшой полезной нагрузки утверждений. Это стандартный формат учётных данных для stateless-сессий в вебе, ID-токенов OAuth/OIDC, аутентификации API «машина-машина» и подписанных magic-ссылок. JWT всегда состоит из трёх сегментов base64url, соединённых точками: header.payload.signature. Заголовок и полезная нагрузка — это JSON; подпись — это двоичный MAC или цифровая подпись над первыми двумя сегментами.

Как работают JWT?

Когда этот инструмент декодирует токен, он проходит те же три шага, что и любая JWT-библиотека:

  1. Разделить токен по точкам ровно на три непустых сегмента. Любая другая форма считается некорректной.
  2. Декодировать сегменты 0 и 1 из base64url, затем выполнить JSON.parse для каждого. Заголовок содержит алгоритм (alg) и тип токена (typ). Полезная нагрузка содержит утверждения (sub, exp, iat, пользовательские ключи).
  3. Если задан секрет, пересчитать MAC над <segment0>.<segment1>, используя алгоритм из заголовка. Сравнить байты с третьим сегментом.
  4. Показать результат проверки вместе с декодированными утверждениями, включая понятный человеку индикатор истечения срока, вычисленный из утверждения exp.

Зачем декодировать JWT в браузере?

Вставка реального, используемого JWT в удалённый отладчик передаёт учётные данные в логи этого сервиса, его стек наблюдаемости и любому партнёру, которому сервис отправляет данные. Даже если сторонний сайт заявляет, что не логирует токены, у вас нет способа это проверить. Этот инструмент создан так, чтобы вам никогда не приходилось идти на такой компромисс:

  • Нулевая сеть: в исполняемой среде нет вызовов fetch, XMLHttpRequest или sendBeacon. Откройте DevTools во время декодирования и проверки — панель Network останется пустой.
  • Нативный Web Crypto: проверка HMAC использует crypto.subtle.importKey и crypto.subtle.sign — те же примитивы, что вызвала бы ваша среда исполнения.
  • Статический деплой: каждая страница — это единственный статический HTML-файл без серверного эндпоинта, который можно скомпрометировать. Здесь нечему утекать, потому что нет сервера, с которого могла бы произойти утечка.

Что проверяет этот инструмент, а что нет?

Версия 1 этого инструмента проверяет только подписи семейства HMAC-SHA. Конкретно:

  • Поддерживается: HS256, HS384, HS512. Укажите общий секрет, и инструмент пересчитает и сравнит MAC.
  • Пока не поддерживается: RS256/384/512 (RSA), ES256/384/512 (ECDSA), EdDSA и PS256/384/512 (RSA-PSS). Они требуют открытого ключа в формате PEM или JWK и намеренно отложены до следующего релиза.
  • Отклоняется: alg: "none". Инструмент декодирует токен, но явно отмечает его как небезопасный — никакая проверка подписи не происходит, и любая продакшен-система, принимающая такой токен, имеет серьёзную уязвимость.

Как выглядит пример декодирования JWT?

Вставьте канонический пример токена из RFC 7519 в поле ввода выше:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Заголовок декодируется в {"alg":"HS256","typ":"JWT"}, а полезная нагрузка — в {"sub":"1234567890","name":"John Doe","iat":1516239022}. Введите your-256-bit-secret в панели проверки, и проверка подписи вернёт «действительна». Измените хотя бы один символ секрета — и она вернёт «недействительна». Ничто из этого не покидает ваш браузер.

Это тот декодер JWT, который мы хотели иметь, когда нужно было отлаживать токен в продакшене: уважающий конфиденциальность, быстрый и построенный на тех же примитивах, что использует исполняемая среда.