博客
🌐 简体中文
English简体中文
探索工具 →

JWT Token 是什么？在线解析教程

一篇讲清 JSON Web Token（JWT）原理的教程：Header、Payload、Signature 分别是什么，如何在浏览器里免费在线解析 JWT，看懂过期时间和常见字段。

5 分钟阅读

打开浏览器开发者工具，看到 Cookie 或请求头里一长串 eyJhbGciOiJIUzI1NiIs... 这样的字符串，很多人第一反应是"这是加密后的密文吗？"。其实不是——这是一个 JWT Token，本文帮你搞懂它到底是什么、里面藏了什么信息，以及如何在几秒内在线解析出来。

JWT 是什么

JWT 全称 JSON Web Token，是一种紧凑、URL 安全的方式，把一组"声明"（claim，即事实信息）打包成一段带签名的文本，最常见的用途是登录后用来证明"我是谁"。服务端不再需要在内存或数据库里维护会话状态，而是把用户身份编码进一个 Token 交给客户端，客户端在之后的每次请求里把这个 Token 带回来。

需要特别注意：JWT 默认不是加密的，只是编码 + 签名。任何拿到 Token 的人都能读出里面的内容；签名的作用只是证明内容没被篡改过（前提是签名密钥没有泄露）。这是理解 JWT 最关键的一点——永远不要把敏感信息塞进 Payload。

JWT 的三个部分

一个 JWT 永远是三段 Base64Url 编码的字符串，用英文句号连接：

header.payload.signature
部分 内容 典型字段
Header（头部） Token 元信息 alg（签名算法，如 HS256）、typ（类型，通常为 JWT）
Payload（载荷） 真正的声明信息 sub（用户 ID）、iat（签发时间）、exp（过期时间）、以及业务自定义字段如 name、role
Signature（签名） 完整性校验 对 Header + Payload 做 HMAC 或 RSA/ECDSA 签名

前两段本质上只是 Base64Url 编码后的 JSON，没有任何加密。这也是为什么任何 JWT 解析工具都能瞬间还原出里面的原始声明。

如何在线解析 JWT

不需要写后端代码、不需要命令行工具，也不需要把生产环境的 Token 粘贴到不知道会不会被记录日志的陌生网站。JWT 解码 工具完全在浏览器本地运行：

  1. 打开 JWT 解码工具。
  2. 把 Token 粘贴到输入框（格式为 xxxxx.yyyyy.zzzzz），或者点击 示例 Token 试用一个演示 Token。
  3. 工具会把 Token 拆成 Header、Payload、Signature 三部分，并把 Header 和 Payload 渲染成清晰的键值对列表。
  4. 时间类字段（exp、iat、nbf）会自动转换成可读日期，并附上相对时间提示，比如"2 小时后"或"3 天前"，不用自己手动换算 Unix 时间戳。
  5. 顶部状态栏会根据 exp 与当前时间对比，直接告诉你 Token 处于有效、即将过期还是已过期状态。
  6. 点击 Header 或 Payload 旁的复制按钮，即可把格式化后的 JSON 复制到剪贴板，方便记录或提交 bug 报告。

因为全部处理都在浏览器本地完成，你的 Token 不会上传到任何服务器——这一点对于携带真实登录状态的 Token 尤其重要。

常见 JWT 字段速查

字段 含义
sub Subject，通常是 Token 所代表的用户 ID
iat Issued At，Token 签发时间的 Unix 时间戳
exp Expiration，Token 过期时间的 Unix 时间戳
nbf Not Before，早于此时间的 Token 不应被接受
iss Issuer，签发 Token 的一方
aud Audience，Token 的目标接收方
alg Header 中的签名算法，如 HS256、RS256

如果你看到除以上字段之外的自定义内容（角色、权限、租户 ID 等），这很正常——JWT 的 Payload 本质就是一个 JSON 对象，业务系统可以在里面塞任何需要的字段。

"解析"不等于"验签"

这是最容易被搞混的一点：解析 JWT 只能告诉你它声明了什么，不能证明这些声明是可信的。 验签需要用正确的密钥（或公钥）重新计算签名并比对是否一致。像 JWT 解码 这样的工具，故意不做签名验证，只做 Base64Url 解码展示原始内容，并明确标注"仅解码，不验证签名"。

这意味着：

  • 调试很好用：排查接口报错原因、确认 Token 对应哪个用户/角色、查看会话什么时候过期。
  • 不能当安全校验用：绝对不要在自己的后端代码里把"解析出来的 Payload"当作身份证明来信任。服务端用真实签名密钥做验签是必须单独完成的步骤。

如果你在做后端开发，JWT 的验签逻辑应该放在后端框架或认证库里，用密钥去校验——而不是信任前端解码出来的内容。

用 JWT 解析工具排查问题的小技巧

  • "Token 已过期"报错：把 Token 粘进解析工具，看 exp 对应的相对时间。如果显示"2 小时前"，说明该刷新 Token 了，不是接口逻辑的问题。
  • 权限不对：检查 Payload 里的 role、scope 或自定义字段——常见 bug 是角色变更后前端还在用旧 Token 的缓存。
  • 格式错误提示：如果工具提示格式无效，检查是否完整复制了三段用点分隔的内容，是否不小心带上了 Bearer 前缀或多余的空格。
  • 时间戳单位搞混：exp/iat 是 Unix 秒，不是毫秒。如果需要单独换算某个时间戳，可以用 时间戳转换。
  • 想手动看编码细节：JWT 每一段本质就是 Base64Url，如果想单独看某一段的编码过程，也可以用 Base64 编解码 试试。

常见问题

把生产环境的 JWT 粘贴到在线工具安全吗？

如果工具完全在浏览器本地运行、从不把 Token 发到服务器，就是安全的——这里的 JWT 解码工具正是用 atob/JSON.parse 在本地完成解析，不会上传任何内容。遇到没有说明这一点的工具，尤其是生产环境的 Token，建议谨慎使用。

能用这个工具修改并重新签发 JWT 吗？

不能。这个解码工具设计上是只读的——只展示 Header 和 Payload，不支持修改后重新签名，因为重新签名需要私钥，也不是一个应该在前端完成的操作。

为什么 Payload 里有我没设置过的字段？

很多认证服务会在你自己业务字段之外自动加上标准字段（iss、aud、iat 等）。这是 JWT 的正常行为，不是 bug。

"签名未验证"具体是什么意思？

意思是工具只解码展示了 Header 和 Payload 的文本内容，没有用密钥去校验签名的正确性。签名本身仍会以原始字符串形式展示出来，方便你需要时手动比对。

JWT 和 API Key 是一回事吗？

不是。API Key 通常是一段静态、不透明的密钥；JWT 是结构化、自带内容的 Token，携带具体声明并内置过期时间，这也是它更适合会话/登录场景而不是长期 API 访问的原因。

怎么知道自己的 Token 用的是哪种签名算法？

看解析出来的 Header 里的 alg 字段，常见取值有 HS256（基于共享密钥的 HMAC）和 RS256（基于公私钥对的 RSA）。

小结

一个 JWT 说到底就是三段用点连接的 Base64Url 编码文本：Header、Payload、Signature。解析它是即时的，不需要服务端参与；而验证它的真实性则需要签名密钥，是完全独立的另一件事。下次需要查看某个 Token 里到底装了什么，直接打开 JWT 解码 工具，在浏览器里一眼看清它的声明和过期时间。

继续阅读