JWT 解码器

在本地解码 JSON Web Token 的头部和载荷。放心查看声明，但记住：解码不等于验签。

token.jwt
decoded.json
粘贴 JWT 来解码 header 和 payload。解码不会验证签名。

解码 JSON Web Token（JWT）

粘贴一个三段式 token，点 Decode。工具会按 header.payload.signature 拆开，对前两段做 Base64url 解码，再当作 JSON 解析。这样你不用把 token 发给某个解码 API，就能查看它声明的算法和各项声明。

对签名过的 JWT 来说，第三段是密码学签名 —— 本页不验证这个签名。加密型 JWT 是另一种五段式紧凑序列化格式，不在这个解码器的范围内。

解码不等于验签

拿到一个标准签名 JWT 的人，都能读出它的头部和载荷。Base64url 是编码方案，不是加密方案。解出来的 JSON 只告诉你 token 说了什么，说不清是谁签发的、内容有没有被改过，也说不清你的应用该不该信它。

验签应该在消费 token 的那个系统里做：用维护良好的 JWT 库，配上可信的密钥，限定可接受的算法，再校验 issuer、audience 这些应用相关的要求。不要拿这个解码器的输出去做授权决策。

常见声明

  • iss 标识签发方。
  • sub 标识主体。
  • aud 标识目标受众。
  • exp、iat、nbf 是 NumericDate 值，表示从 Unix 纪元起算的秒数。

当 exp 是数字时，解码器会给出一个过期提示。这个基于本地时钟的比较调试时很方便，但作为校验远远不够。真正的验证还要考虑可信时间源、允许的时钟偏差、签发方规则、吊销或会话状态，以及你整套认证设计里的其余部分。

非必要就别粘贴仍然有效的 token

解码逻辑虽然在浏览器里跑，但 bearer token 本身就是凭据：任何人拿到一个有效的都可能用它冒充你。调试时请用本地测试环境的 token，或者改掉声明后重新签一个测试用的。永远不要把密码、私钥或其他机密放进 JWT 载荷 —— 签过名的载荷照样是能读的。

想看更完整的讲解，见 如何解码 JWT。如果要处理的是标准 Base64 文本而不是 JWT 的 Base64url 分段，请用 Base64 工具。

FAQ

这个工具会验证 JWT 签名吗？

不会，它只解码头部和载荷。在依赖 token 的应用里，请用成熟的库验证签名和所有必需的声明。

签过名的 JWT 能藏住载荷吗？

不能。签名在验证正确的前提下保证的是完整性和真实性，但它不加密声明内容。需要机密性的话，请改用合适的加密型 token 方案。