JWT解码工具

解码并检查JSON Web Token

加载示例

JWT令牌

本地运行 · 粘贴密钥安全无忧
也可以试试:JWT Encoder

什么是 JWT(JSON Web Token)?

JSON Web Token(JWT)是一种紧凑、URL 安全的令牌格式,由 RFC 7519 定义。它将一组声明(claims)编码为 JSON 对象,然后对其进行签名——并可选择加密——以便接收方能够验证数据未被篡改。JWT 是 REST API、单点登录系统和微服务授权中无状态认证的事实标准。

JWT 结构:Header · Payload · Signature

每个 JWT 由三个以点分隔的 base64url 编码段组成。Header 和 Payload 是普通 JSON——任何人都可以读取——而 Signature 是一个加密值,只有使用正确的密钥才能验证。

编码后的令牌

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HeaderPayloadSignature
Header
json
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
json
{
  "sub":  "user123",
  "name": "Alice",
  "role": "admin",
  "iat":  1717200000,
  "exp":  1717203600
}

为什么要使用 JWT 解码器?

原始 JWT 看起来像随机文本。此工具可立即将 Header 和 Payload 渲染为格式化的 JSON,让您无需编写任何代码即可检查声明、核查过期时间并审查算法选择。

🔍
即时查看声明
以一键方式查看 Payload 中的每个声明——sub、iss、aud、exp、自定义角色、权限——格式化且清晰可读。
🔓
无需密钥
Header 和 Payload 是公开的;只有 Signature 需要密钥。此工具无需签名密钥即可解码两者。
⏱️
过期时间与时间戳解析
Unix 时间戳(exp、iat、nbf)会自动转换为可读日期,让您立即判断令牌是否已过期。
🔒
完全在浏览器中运行
所有处理均在本地完成——不会将任何令牌数据发送到服务器。在调试时使用生产令牌也很安全。

JWT 标准声明参考

RFC 7519 定义了七个已注册的声明名称。这些并非强制要求,但强烈建议使用以确保互操作性。您可以在 Payload 中添加任意自定义声明。

声明说明类型
iss签发者标识令牌的签发方——例如您的认证服务器 URL 或应用名称。string
sub主题标识 JWT 所描述的主体——通常是用户 ID 或服务账号。string
aud受众标识预期接收者。接收方必须验证此值与其自身标识符匹配。string | string[]
exp过期时间Unix 时间戳,超过此时间后令牌不得被接受。务必设置此值以限制令牌被盗后的损害。number
nbf生效时间Unix 时间戳,在此时间之前令牌不得被接受。适用于安排未来生效的令牌。number
iat签发时间令牌签发时的 Unix 时间戳。用于计算令牌的使用时长。number
jtiJWT ID令牌的唯一标识符。通过在服务端存储和检查已使用的 JTI 值来实现令牌吊销。string

JWT 签名算法

Header 声明 alg 标明签名所用的算法。选择会影响安全性、性能,以及第三方服务能否在不持有私钥的情况下验证令牌。

算法算法族密钥类型备注
HS256HMACSymmetric最常用。共享密钥——任何持有密钥的人都可以签名和验证。
HS384HMACSymmetric更强的 HMAC 变体;有一定性能开销。
HS512HMACSymmetric最强的 HMAC 变体。
RS256RSAAsymmetric最广泛使用的非对称算法(Google、Auth0、Okta)。公钥可在不持有私钥的情况下进行验证。
RS384RSAAsymmetric安全性更高的 RS 变体。
RS512RSAAsymmetric最强的 RS 变体。
ES256ECDSAAsymmetric椭圆曲线——签名比 RSA 更短,在移动端和 IoT 设备上广受欢迎。
PS256RSA-PSSAsymmetricRSA-PSS:比基于 PKCS1v1.5 的 RS256 更现代、更安全。
none无签名——极度危险。生产环境中绝不接受 alg: none 的令牌。

安全注意事项

解码 JWT 本身始终是安全的。但在未进行正确签名验证的情况下信任 JWT 则不安全。在应用中使用令牌时,请牢记以下规则。

始终安全
  • 在开发者工具或此工具中解码和检查 JWT
  • 使用 exp、iat 和 nbf 了解令牌的有效期
  • 记录 Payload 声明用于调试(省略敏感个人信息)
  • 读取 alg header 以了解令牌的签名方式
绝不做这些
  • 在未于服务端验证签名的情况下信任 Payload 中的声明
  • 接受 alg: none 的令牌——这意味着完全没有签名
  • 在高安全要求的应用中将访问令牌存储在 localStorage(应优先使用 httpOnly cookie)
  • 为携带敏感权限的令牌将 exp 设置得过于靠后

常见使用场景

调试认证流程
从浏览器的网络选项卡粘贴令牌,检查声明、验证内嵌角色并核查过期时间,无需修改生产代码。
检查第三方令牌
快速读取来自 Google、Auth0、Okta 或 Azure AD 的令牌,查看提供方包含哪些声明,并与预期的模式进行比对。
API 开发与测试
在编写或测试 API 端点时,解码 Authorization header 以确认令牌生成逻辑正确设置了 sub、aud 和 scope 值。
微服务授权
在服务网格中,每个服务都会验证上游调用方的 JWT。解码令牌以追踪哪个服务签发了令牌,以及它声称拥有哪些权限。
支持与事故响应
当用户报告认证错误时,解码其令牌以检查是否已过期、受众是否有误,或是否缺少必要声明。
安全审计
通过检查算法选择、过期时间窗口以及是否意外将敏感数据存储在未加密的 Payload 中,审计各服务中 JWT 的使用情况。

在代码中解码 JWT

Header 和 Payload 使用 base64url 编码——只需反向解码即可。Base64url 将 + 替换为 -,将 / 替换为 _,并省略 = 填充。只有 Signature 需要密钥。

JavaScript (browser)
function decodeJWT(token) {
  const [, payload] = token.split('.')
  const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
  return JSON.parse(json)
}
Node.js
const [, payload] = token.split('.')
const decoded = JSON.parse(
  Buffer.from(payload, 'base64url').toString()
)
Python
import base64, json

def decode_jwt(token):
    payload = token.split('.')[1]
    padding = '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload + padding))
CLI (bash + jq)
TOKEN="eyJhbGc..."
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .

常见问题

不知道密钥也能解码 JWT 吗?
可以。JWT 的 Header 和 Payload 只是 base64url 编码的 JSON——并未加密。任何人都可以解码并读取。密钥(或 RS/ES 算法的私钥)仅用于验证签名,以确认令牌未被篡改。
解码 JWT 是否意味着签名已被验证?
不。解码只是读取声明。验证是一个独立步骤,需使用正确密钥检查加密签名。在应用中信任任何声明之前,务必先验证签名。
HS256 和 RS256 有什么区别?
HS256 使用签发者和验证者共享的单一对称密钥——任何持有密钥的人都可以创建和验证令牌。RS256 使用非对称密钥对:私钥签名,公钥验证。使用 RS256 可以分发公钥,让外部服务验证令牌而无法伪造。
为什么 base64 解码有时会失败?
JWT 使用 base64url 编码,将 + 替换为 -,将 / 替换为 _,并省略填充字符 =。标准 base64 解码器需要 + 和 /,且可能需要填充。手动解码前,请先补充填充(用 = 补足4的倍数)并替换字符。
将生产环境的 JWT 粘贴到此工具安全吗?
安全——此工具完全在浏览器中运行,不向任何服务器发送数据。但请注意周围是否有人可以看到您的屏幕或浏览器历史记录。对于高度敏感的令牌,建议在终端中本地解码。
alg: none 意味着什么?危险吗?
alg: none 表示令牌没有加密签名——任何人都可以用任意声明创建令牌并将 alg 设为 none。一些早期的 JWT 库接受此类令牌,导致严重漏洞。安全的 JWT 库始终拒绝 alg: none 的令牌,除非明确配置允许。绝不要禁用此检查。