JWT 解码器

即时解码和查看 JWT（JSON Web Token）的 Header、Payload 和 Signature。免费在线工具，无需上传数据。

在浏览器中处理
数据不离开你的设备
免费 · 无需注册

点「解码」立即运行；焦点在工具内时 Ctrl/⌘+Enter 执行相同操作。输入符合三段 Base64URL 格式时也会在 300 毫秒后自动解码。其他输入可点「解码」查看错误。

「加载示例」替换输入并立即解码一个 HS256 令牌，内容含 John Doe、iat 1516239022 和 exp 1893456000。

点「清除」，或焦点在工具内时按 Ctrl/⌘+L，会清除令牌、结果和状态，并取消等待中的自动解码。

粘贴 JWT Token 粘贴以点号分隔的三段 Base64URL。Header 和 Payload 按 UTF-8 解码，允许省略填充符。签名为空的令牌也可查看。令牌不会保存或上传。

解码不验证签名。“valid”仅表示按本机时钟判断过期时间尚未过去。

解码结果 Header 和 Payload 显示高亮 JSON，各自的「复制」按钮复制缩进为两个空格的 JSON，不含日期注记。Signature 显示原始 Base64URL 字符串，不验证签名。

时间声明 Payload 中数值类型的 exp、iat、nbf 会附 UTC 日期，匹配的嵌套字段也适用。数值单位是秒。仅 exp 按本机时钟显示 valid 或 EXPIRED；这不代表签名验证。

解码后，这里显示 Header、Payload 和原始 Signature。

阅读完整使用指南 JWT 完全指南：解码、验证与常见安全陷阱

示例、说明与常见问题带实际输出的示例、与同类工具的差别，以及常见问题。

示例：查看业务系统签发的登录令牌

下面这个令牌由本站测试脚本用演示密钥 zerotool-demo-secret-zh 按 HS256 签出，不对应任何真实系统。载荷里有中文姓名和部门，iat 是北京时间 2026 年 10 月 5 日 8:00，exp 是同一天 23:59:59。把它粘贴进输入框，点「解码」：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMDA4NiIsIm5hbWUiOiLlvKDkuIkiLCJkZXB0Ijoi56CU5Y-R6YOoIiwiaWF0IjoxNzkxMTU4NDAwLCJleHAiOjE3OTEyMTU5OTl9.ra4F_l6uSTHmzMT6AOWLglbAZB1oSvSQVyT-GAW-9is

Payload 区域显示下面的 JSON（点「复制」得到的也是它，不带日期注记）：

{
  "sub": "10086",
  "name": "张三",
  "dept": "研发部",
  "iat": 1791158400,
  "exp": 1791215999
}

在北京时间 10 月 5 日早上 8 点打开时，iat 旁显示 Mon, 05 Oct 2026 00:00:00 GMT，exp 旁显示 Mon, 05 Oct 2026 15:59:59 GMT — valid。注记是 UTC，加 8 小时才是北京时间：00:00:00 对应 8:00:00，15:59:59 对应 23:59:59。北京时间当天 23:59:59 之后再打开，exp 旁就会变成 EXPIRED。

「张三」「研发部」能正常显示，是因为工具先把 Base64URL 还原成字节，再按 UTF-8 解码。封闭系统之外交换的 JSON 必须用 UTF-8（RFC 8259 §8.1）。如果令牌是旧系统按 GBK 编码后签发的，中文通常会显示成替换字符 �，个别字会变成别的字符（如「模」的 GBK 字节 C4 A3 恰好是 UTF-8 的「ģ」）。

粘贴时常见的几种失败

从接口文档、抓包工具或日志里复制令牌时，经常多带或少带几个字符。下面三种情况都要点「解码」才会看到提示，自动解码不会触发：

连 Bearer 一起复制。从请求头 Authorization: Bearer eyJ… 里复制时，如果带上了 Bearer ，状态栏显示 Base64URL 解码失败。只保留 eyJ 开头的部分即可。
连引号一起复制。接口返回 {"token": "eyJ..."} 时，复制的值如果带着两端的双引号，同样显示 Base64URL 解码失败。
只复制了前两段。令牌太长、被界面折行时，容易漏掉最后一段签名。输入 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMDA4NiJ9 会显示 JWT 无效：应有 3 段，实际为 2.。注意不带签名的 JWT（alg 为 none）结尾也有一个点，签名为空也是三段，可以正常解码。

exp 写成了毫秒怎么办

JWT 的时间声明是 NumericDate，单位是秒（RFC 7519 §2）。Java 的 System.currentTimeMillis() 返回的是毫秒，如果直接拿它算 exp，数值会大 1000 倍。下面这个演示令牌就是这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOjEwMDg2LCJpYXQiOjE3OTExNTg0MDAsImV4cCI6MTc5MTIxNTk5OTAwMH0.9EaBcmkknqdMb0CmhJXZiLrWYNVcETdtgwq-X4Rf0Zg

iat 旁正常显示 Mon, 05 Oct 2026 00:00:00 GMT，exp 旁却显示 Mon, 18 May 58731 15:43:20 GMT — valid。年份变成五位数，就说明这个值是毫秒。这种令牌几乎永不过期，服务端校验 exp 时也拦不住它，应在签发处除以 1000。

解码不等于验证

Header 和 Payload 只是 Base64URL 编码，任何人都能解码，也能改掉其中的字段后重新编码。本工具不检查签名，所以一个被改过 Payload 的令牌在这里看起来和真令牌一模一样。服务端不能因为令牌「能解码」就信任它：要用签发方的密钥验证签名，再检查 exp、nbf、iss、aud（RFC 8725 §3）。要生成带自定义声明的测试令牌，可以用 JWT 生成器 / 签名器。

限制

令牌中的换行，以及换行前后的空格和制表符，会被忽略：从日志或邮件里复制、被折成几行的令牌照常解码，状态栏显示 解码成功。。Header 或 Payload 中间的其他空格或制表符会导致解码失败。
只有 exp、iat、nbf 且值为数字（单位为秒）时才显示 UTC 日期，嵌套对象里的同名字段也会显示。原始数值保持不变，日期注记只显示到整秒。
「valid」「EXPIRED」、签名区的「not verified」说明和「(unable to parse)」在所有语言页面上都是英文。
Header 或 Payload 能解码但不是 JSON 时，对应区域显示「(unable to parse)」。
加密的 JWE 有五段，没有密钥无法读取，这里会提示应有 3 段（RFC 7516 §3）。
令牌不会保存到任何地方。JWT 常常就是登录凭据，所以本页不加载统计和广告脚本。

JWT 的三个部分

JSON Web Token（JWT）是一种紧凑、可放进 URL 的令牌格式，常用于登录态和接口鉴权。它由三段 Base64URL 编码的内容组成，用点号分隔：

Header：签名算法（如 HS256、RS256）和令牌类型。
Payload：声明，即关于用户等实体的数据和附加信息。
Signature：用来确认令牌没有被改过，验证时需要密钥或公钥。

常见的注册声明有 sub（主体）、iss（签发方）、exp（过期时间）、iat（签发时间）、nbf（生效时间）和 aud（受众）。

FAQ

我的 JWT 会发送到服务器或被保存吗？

不会。解码在浏览器里用 JavaScript 完成，令牌不会发送到任何服务器，也不会写入浏览器存储。本页不加载 Google Analytics 和 AdSense。

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

不能。验证签名需要签发方的密钥或公钥。本工具只解码并显示 Header 和 Payload，Signature 原样显示，用来查看声明内容。

JWT 的三个部分是什么？

JWT 由三段 Base64URL 编码的内容组成，用点号分隔：Header（签名算法和令牌类型）、Payload（声明数据）和 Signature（用于校验令牌是否被改过）。

Payload 里的 exp 是什么意思？

exp 是过期时间声明，值是以秒为单位的 Unix 时间戳。本工具在原始数值旁显示可读日期，并按本机时钟标出 valid 或 EXPIRED。

为什么显示的时间比北京时间早 8 个小时？

日期注记一律按 UTC 显示（写作 GMT），不随设备时区变化。北京时间是 UTC+8，看到的时间加 8 小时即可：Mon, 05 Oct 2026 15:59:59 GMT 就是北京时间 10 月 5 日 23:59:59。valid 或 EXPIRED 直接比较秒数与本机时钟，与时区无关。