Что делает декодер JWT
JSON Web Token (JWT) выглядит как длинная непрозрачная строка случайных символов, но он не зашифрован и не является тайным шифром. Это компактный, безопасный для URL контейнер, который переносит структурированные данные между двумя сторонами. Вставьте токен в декодер выше — и он разобьёт эту строку и покажет реальный JSON внутри: метаданные, утверждения, для кого выдан токен и когда истекает. Всё происходит прямо в браузере. Токен никогда не загружается, не записывается в лог и никуда не отправляется, а это принципиально важно, когда проверяется живой сессионный токен.

Три части, две точки
Каждый корректный JWT — это три строки в кодировке Base64url, соединённые точками: header.payload.signature. Именно одиночная точка говорит парсерам, где заканчивается один раздел и начинается следующий, и именно поэтому токен с неправильным количеством точек отвергается ещё до того, как будет прочитано хоть что-то ещё.
Заголовок — небольшой JSON-объект, описывающий сам токен. В нём почти всегда содержатся typ (тип, обычно JWT) и alg — алгоритм подписи, например HS256 (HMAC с SHA-256) или RS256 (RSA с SHA-256). Заголовок сообщает верификатору, как именно была создана подпись.
Полезная нагрузка — это та часть, которая интересует большинство разработчиков. Это ещё один JSON-объект, содержащий утверждения — сведения о пользователе и токене. Спецификация разделяет утверждения на зарегистрированные (стандартные, зарезервированные имена), публичные и приватные (собственные имена для вашего приложения). Декодирование полезной нагрузки раскрывает, кто вошёл в систему, какова его роль и когда истекает сессия.
Подпись — это криптографическая печать. Она вычисляется на основе закодированного заголовка и полезной нагрузки с использованием алгоритма из заголовка и секретного или приватного ключа. Поскольку подпись охватывает оба других раздела, любое изменение в заголовке или полезной нагрузке — даже один символ — делает её недействительной.
Наиболее распространённые утверждения
Зарегистрированные утверждения — это короткие трёхбуквенные имена, определённые в RFC 7519, чтобы разные системы могли взаимодействовать. Несколько из них встречаются почти везде:
iss— issuer (издатель): кто выпустил токен (ваш сервер авторизации или провайдер идентификации).sub— subject (субъект): принципал, которому относится токен, как правило стабильный идентификатор пользователя.aud— audience (аудитория): получатель, для которого предназначен токен. API должен отклонять токены с чужой аудиторией.exp— expiration time (время истечения): Unix-временная метка, после которой токен не должен приниматься.iat— issued at (время выдачи): Unix-временная метка создания токена.
Вы также можете встретить nbf (не раньше) и jti (уникальный идентификатор токена). Временные метки — это секунды с начала 1970 года в UTC, поэтому декодер, отображающий их в виде читаемых дат, избавляет от умственных усилий при проверке того, не истёк ли токен.
Декодирование — это не верификация: именно здесь совершают ошибки
Это различие — самое важное, что нужно понять о JWT. Декодирование означает чтение содержимого: ключ для этого не нужен, и любой, у кого есть токен, может это сделать, потому что Base64url — это кодирование, а не шифрование. Верификация означает доказательство того, что токен подлинный и не изменён — пересчёт подписи с правильным секретным или публичным ключом и проверка совпадения.
Этот инструмент декодирует. Он показывает, что токен говорит, а не является ли токен достоверным. Токен может быть поддельным, просроченным или воспроизведённым повторно — и при этом декодироваться в идеально чистый JSON. Никогда не принимайте решение об авторизации только на основе декодированных утверждений. В продакшене подпись верифицируется на стороне сервера, проверяется exp и подтверждается совпадение iss и aud с ожидаемыми значениями — с помощью проверенной библиотеки, но никак не самодельного сравнения строк.

Полезная нагрузка — не хранилище секретов
Поскольку полезная нагрузка лишь закодирована в Base64url, её может прочитать любой, кто перехватит токен. Относитесь ко всему в ней как к публичной информации. Не помещайте в утверждения JWT пароли, полные номера банковских карт, секретные ключи или какие-либо конфиденциальные персональные данные — если вы можете декодировать это здесь одним кликом, то же самое может сделать любой, кто получит копию. Подпись защищает от изменения, но не от чтения. Если содержимое полезной нагрузки действительно нужно скрыть, это задача для JWE (зашифрованных токенов) — совершенно другой спецификации.
Конфиденциальность и связанные инструменты
Работа с токеном — деликатное дело, поэтому декодер работает полностью на стороне клиента — разбор выполняется обычным JavaScript в вашей вкладке и ничто не покидает ваше устройство. Вставить сессионный токен в серверный инструмент — значит передать живые учётные данные третьей стороне, а именно этого следует избегать. Об основах кодирования читайте в описании нашего инструмента Base64, а другие утилиты, работающие локально, найдёте в разделе инструментов разработчика.
Часто задаваемые вопросы
JWT зашифрован?
Нет. Стандартный JWT закодирован в Base64url, а не зашифрован. Любой, у кого есть токен, может прочитать заголовок и полезную нагрузку. Если нужно скрыть содержимое, используйте JWE.
Этот инструмент проверяет подпись?
Нет. Он только декодирует и отображает заголовок и полезную нагрузку. Верификация подписи требует секретного или публичного ключа издателя и должна выполняться на вашем сервере.
Безопасно ли вставлять токен сюда?
Да. Декодирование происходит полностью в браузере с помощью локального JavaScript. Токен никогда не загружается, не сохраняется и не отправляется ни на какой сервер.
Что означают iss, sub, aud, exp и iat?
Это зарегистрированные утверждения: издатель, субъект, аудитория, время истечения и время выдачи. Три связанных со временем значения используют Unix-временные метки в секундах.
Можно ли доверять утверждениям, показанным после декодирования?
Не самим по себе. Декодированные утверждения могут исходить из поддельного или просроченного токена. Всегда верифицируйте подпись и проверяйте время истечения на стороне сервера, прежде чем им доверять.
Почему мой токен состоит из трёх частей, разделённых точками?
Это заголовок, полезная нагрузка и подпись, каждая из которых закодирована в Base64url и соединена точками. Точки сообщают парсерам, где начинается и заканчивается каждый раздел.
