JWT 解析器

JWT 解码器会把令牌中可见的部分还原成可读 JSON，让你不必手动拆分 Base64URL 片段就能检查认证数据。它最适合排查登录失败、接口 401/403、环境串错、权限范围不一致、过期时间异常等问题；但它本身并不负责证明这个令牌可信。

工具边界

本页当前能力限定为解码与检查：不会要求输入 secret 或公钥，不会验证 signature，也不会生成或重新签发 JWT。

JWT 是三段 Base64URL 内容，不是一团加密密文

常见签名 JWT 写作 `header.payload.signature`。其中 header 和 payload 通常是经过 Base64URL 编码的 JSON；Base64URL 使用适合 URL 的字符集，并可能省略填充字符。拿到令牌的人都能解开这两段 JSON，所以“能读到 payload”是 JWT 的常规属性，不能把它误解成已经完成授权。

• Header：描述令牌类型、签名算法等元数据。
• Payload：承载关于主体、签发者、受众、时间限制、权限范围或业务事实的 claims。
• Signature：用于保护编码后的 header 与 payload，但只有使用正确密钥材料验证后才有信任意义。

需要优先识别的注册声明

如何使用这个工具

1. 粘贴完整的三段式 JWT，让工作区同时解析 header 和 payload。
2. 先检查算法、issuer、audience 以及 exp、nbf 时间，再判断下一步需要验证什么。
3. 把解码结果只当作可读检查视图，签名和关键声明仍要回到真实认证系统里验证。

解码后应按什么顺序阅读

解码 JWT 时最好保持固定阅读顺序，这样能把格式问题和真实认证失败分开。先确认令牌段数是否正常，再看算法和类型，再检查影响签发方、受众、时间、主体与权限范围的声明。

1. 先看 header 里的 `typ` 和 `alg`，再判断 payload。
2. 把时间类 claims 与日志系统使用的时区放在一起核对。
3. 把解码出的自定义 claims 当作排查证据，而不是直接放行权限的依据。

JWT 解析器 示例

这个 JWT 解析器 示例使用有代表性的由 Base64URL header、payload 和 signature 组成的 JWT 字符串，展示生成后的可阅读的令牌 header 与 payload JSON，便于你先确认三段式令牌结构、Base64URL 解码、exp 与 nbf 时间、issuer、audience，以及解码不等于验签，再把同样设置用于真实输入。

示例输入

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.signature

预期输出

{
  "alg": "HS256"
}
{
  "sub": "123"
}

Header 与 Payload 解码示例

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

Payload:
{
  "sub": "toolkit-user",
  "name": "ToolKit Online",
  "iat": 1700000000
}

Signature:
存在，但本解码器不会验证它

仅解码检查的安全伪代码

parts = token.split(".")
if parts.length < 2:
  rejectAsMalformed()

header = parseJson(base64UrlDecode(parts[0]))
payload = parseJson(base64UrlDecode(parts[1]))
signatureSegment = parts[2] || ""

show(header, payload, signatureSegment)
warn("解码结果不等于签名验证")

JWT 解码器最适合哪些排查场景

JWT 解码器本质上是认证与授权排障中的可视化工具。它让开发、支持、接口负责人先围绕“令牌里写了什么”达成共识，再继续检查服务端验签、密钥配置或业务授权规则。

• 确认前端是否把测试环境 token 发到了生产接口，或反过来。
• 当一个 API 接受令牌、另一个 API 拒绝时，对比 `aud`、`iss` 和 scope 类声明。
• 排查突然登录失败、刷新失败时，检查 `exp`、`nbf` 或服务器时钟偏差是否相关。

常见使用场景

JWT 解析器 最适合用在由 Base64URL header、payload 和 signature 组成的 JWT 字符串需要快速变成可阅读的令牌 header 与 payload JSON的场景，尤其是登录排查、API 授权核对、环境不一致、权限声明和支持调查。

• 用于在本地解码 JWT header 和 payload 声明，服务于登录排查、API 授权核对、环境不一致、权限声明和支持调查。
• 处理重要输入前，可先用示例流程确认三段式令牌结构、Base64URL 解码、exp 与 nbf 时间、issuer、audience，以及解码不等于验签。
• 当结果符合目标流程后，再复制或下载可阅读的令牌 header 与 payload JSON。

解码器真正适合帮你检查什么

JWT 解码页最有价值的场景，是登录排查、接口联调、环境验证和声明字段核对。它能让你很快确认令牌里有没有预期的用户标识、角色、受众、过期时间和算法声明，从而快速缩小问题范围。但只要问题已经触及“这个令牌能不能被信任”，判断权就必须交回真实认证链路，而不是停留在页面上看到的可读内容。

• 解码视图适合检查声明是否存在，不适合绕过服务器端真正的验证规则。
• 排查认证失败时，最好把 `exp`、`nbf`、`iss`、`aud` 和算法声明一起看，而不是只盯着某一个字段。
• 还要记住 JWT 使用的是 Base64URL 变体，它与标准 Base64 在字符集和填充处理上可能略有不同。

解码绝对不等于验签

这是 JWT 工具页里最关键的边界。你把 token 解析开，只说明你看懂了它长什么样，并不说明这个 token 来自可信签发者，也不说明签名一定正确、更不说明它现在仍然有效。真正的验签和接受逻辑，必须回到认证系统里完成。

• 排查问题时，至少要结合 `exp`、`nbf`、`iss`、`aud` 以及业务自定义 claims 一起看。
• 复制生产环境 token 时也要谨慎，因为 payload 里可能含有用户、会话或权限范围信息。

算法字段只是上下文，不是本地可信结论

`HS256`、`RS256`、`ES256` 这类值只能说明令牌声称使用了哪种算法。真实验证器仍必须强制算法白名单、选择正确的 secret 或公钥、拒绝不符合预期的 `alg` 值，并在验签后继续校验必要 claims。

• 不要因为 header 里写了某个算法，就直接信任该算法。
• 不要把密码、密钥、私钥或敏感客户数据放进 payload，因为解码后的 payload 是可读的。
• 真实产品中应按需要配合短有效期、HTTPS、密钥轮换、服务端撤销或刷新令牌机制。

几种 JWT 检查动作的区别

JWT 与相邻令牌形态对比

使用注意

• 复用可阅读的令牌 header 与 payload JSON前，先检查三段式令牌结构、Base64URL 解码、exp 与 nbf 时间、issuer、audience，以及解码不等于验签。
• 只有真实认证系统完成签名和必要声明校验后，解码出的 JWT 才能被信任。
• 当结果会影响生产工作或客户可见内容时，应保留原始由 Base64URL header、payload 和 signature 组成的 JWT 字符串以便回退和核对。

JWT 解析器 参考说明

JWT 解析器 会解释 header、payload、signature、过期时间，以及解码和验签不是一回事。

• JWT 通常由三段 Base64URL 内容组成：header、payload 和 signature。
• 其中 header 和 payload 本质上只是经过 Base64URL 编码的 JSON；signature 则是对 `header.payload` 这段 ASCII 文本计算出的签名结果。
• 签名算法既可能是 HS256 这类对称算法，也可能是 RS256/ES256 这类非对称算法，但仅靠解码永远不能证明令牌可信。
• 实际认证中还需要检查 exp、nbf、iss、aud 和签名验证。

参考资料

• RFC 7519: JSON Web Token (JWT)
• RFC 7515: JSON Web Signature (JWS)
• RFC 8725: JSON Web Token Best Current Practices