JWT 解码器

JSON Web Token 是由点连接的三个 base64url 编码段:header.payload.signature。头部和负载是 JSON,签名是对前两段使用 HMAC 或 RSA/ECDSA 签名的输出。本工具按点分割,对各部分进行 base64url 解码,解析 JSON,并将 exp 等标准时间声明呈现为人类可读日期。它不验证签名 —— 原因见下文 FAQ。

示例

JWT 规范中的示例令牌(使用 HS256 和密钥 your-256-bit-secret 签名):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

解码后的头部:

{
  "alg": "HS256",
  "typ": "JWT"
}

解码后的负载:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

为什么我的 JWT 签名被标记为无效?

本解码器不检查签名(见 FAQ),但如果服务器端验证器拒绝你的令牌,通常是以下原因。

• 错误的密钥。 HMAC 密钥哪怕差一个字符,也会生成完全不同的签名。请确认验证服务的 JWT_SECRET 环境变量与签发者一致。
• 算法不匹配。 用 HS256 签名的令牌无法用 RS256 验证。请检查头部的 alg 声明,确保验证器使用相同算法。
• 令牌已过期。 即使签名正确,一旦 exp 已过期,JWT 也会验证失败。解码后的时间声明摘要会明确展示这一点。
• 时钟偏差。 nbf(不得早于)若略在未来,加上服务器时钟漂移,会导致 "令牌尚未生效" 错误。建议在验证器中留小幅余量(如 60 秒)。
• 粘贴时混入空白。 复制粘贴有时会带上前导空格或尾随换行。JWT 必须正好是 header.payload.signature,前后不能有空白。
• alg: none。 若头部中出现 "alg": "none",则该令牌未签名。请在验证器端直接拒绝 —— 千万不要将其视为有效。

这个工具能验证 JWT 签名吗?

不能,而且这是故意的。验证签名需要签名密钥 —— HMAC 共享密钥或非对称公钥。该密钥应保存在签发或消费令牌的服务器上,不应粘贴到网页中。本工具仅用于解码和展示;验证应在你的后端服务器端进行。

JWT 的三个段里各自是什么?

JWT 是 header.payload.signature。头部是描述算法(alg)和令牌类型的 JSON。负载是包含 sub、iat、exp 等声明的 JSON。签名是使用密钥或私钥对前两段进行签名后的 base64url 编码输出。前两段只是编码,并未加密。

我的 JWT 过期了 —— 如何判断?

查看负载中的 exp 声明。它是以秒为单位的 Unix 时间戳。如果 Date.now() / 1000 大于 exp,则令牌已过期。本工具会将 exp、iat、nbf 渲染为人类可读日期,放在负载下方,无需自行计算即可一目了然。

alg: none 是什么,为何危险?

alg: none 是 JWT 的一个特性:签名为空且不被检查。历史上许多库都接受此类令牌,使攻击者能构造负载并将 alg 设为 none 来伪造 JWT。如果看到此头部值,该令牌就是未签名的 —— 不要信任接受它的任何服务器。

你们会保存我在此粘贴的 JWT 吗?

不会。我们不保存你粘贴到解码器中的任何令牌。输入的内容在你关闭或刷新标签页后会被丢弃 —— 没有日志,我们这边也没有关于你检查过的令牌的记录。不过 JWT 在其 exp 之前仍具有访问权限:把它当成密码对待,并在调试后轮换任何生产令牌。

签名部分显示一串看不懂的字符 —— 这正常吗?

正常。签名是 HMAC 或 RSA/ECDSA 的二进制输出,经过 base64url 编码。它不是为人类阅读准备的 —— 只用作加密校验。你应关注的是解码后的头部和负载这两部分 JSON。若签名为空,则令牌是未签名的(alg: none)。