JWT 解码器

关于 JWT(JSON Web Token)

JWT 是由点分隔的三个 base64url 编码部分组成的紧凑、URL 安全令牌：描述签名算法的头部、包含声明(数据)的负载，以及用于验证令牌未被篡改的签名。本工具将头部和负载解码还原为易读的 JSON。

头部和负载只是经过 base64url 编码，而非加密，因此任何人都可以在没有密钥的情况下解码并读取它们——这是设计使然。JWT 的签名防止的是篡改，而不是让内容不可读，因此仅凭解码器永远无法确认令牌是否真正有效。

怎么解码 JWT?exp、iat 是什么意思?

JWT(JSON Web Token)由三段用点号连接的 base64url 编码内容组成:header.payload.signature。要读懂它,按点号把字符串拆开,对 header 和 payload 部分做 base64url 解码,再各自按 JSON 解析即可——解码不需要密钥,只有验证签名才需要。payload 里的 iat(签发时间)和 exp(过期时间)是 Unix 时间戳(从 1970-01-01 起的秒数),本工具会把它们转换成人可读的日期。

解码 JWT 的步骤

1. 把完整的 JWT 字符串(用点号分隔的三段都要有)粘贴到输入框。
2. 工具按点号拆分令牌,对第一段(header)和第二段(payload)做 base64url 解码。
3. 解码后的每一段都按 JSON 解析,并格式化输出,方便阅读。
4. 如果 payload 里有 iat 或 exp 字段,会从 Unix 时间戳转换成可读的本地日期和时间。
5. 第三段(签名)会原样保留,不会被解码或校验,因为验证签名需要签发方的密钥,本工具并不掌握。

JWT 结构与时间戳换算

• iat(签发时间)= 令牌创建时刻对应的 Unix 时间戳,单位是秒
• exp(过期时间)= 令牌应被视为失效的时间点对应的 Unix 时间戳,单位是秒
• base64url = base64 编码的 URL 安全变体,把 + 和 / 替换成 - 和 _,并省略末尾的填充字符

常见 JWT payload 字段

常见问题

解码出 JWT 内容,能证明它是有效或可信的吗?

不能。解码只是显示 header 和 payload 里的内容,并不能说明签名是否真实、令牌是否由可信来源签发、内容有没有被篡改。只有用正确的密钥验证签名,才能确认令牌是真实有效的。

为什么不需要密码,任何人都能读到我的 JWT payload 内容?

header 和 payload 只是做了 base64url 编码,并没有加密,所以解码只是一次可逆的文本转换,不是安全屏障——这是设计上的初衷,因为 JWT 本来就是要让收到它的任何一方都能读懂内容。正因如此,敏感数据永远不应该放进 JWT 的 payload 里。

如果令牌的 exp 时间戳已经是过去的时间,会怎样?

对于会检查 exp 的系统来说,exp 是过去时间的 JWT 通常被视为已过期,应该被拒绝;但这个解码工具只负责显示日期,不会拿它和当前时间比较,也不会拒绝任何令牌——这个判断是服务端的责任。

为什么解码出来的令牌显示错误?

出错通常说明粘贴的文本不是一个完整、格式正确的 JWT——比如缺少某个用点号分隔的段落、header 或 payload 不是合法的 base64url 编码,或者解码出来的文本不是合法的 JSON。请检查是否完整复制了整个令牌,没有多余的空格或换行。

这个工具能帮我排查带 JWT 认证的接口问题吗?

可以,这是开发中很常见的用法:把接口返回的令牌粘贴进来,不用写代码就能快速看到里面的用户 ID、角色、过期时间等信息,方便排查登录态或权限问题。不过它始终只是只读的查看工具;如果要真正校验令牌在服务端是否有效,还是需要用对应的 JWT 库和正确的密钥去验证签名。

本工具只解码并显示 header 和 payload,不会验证签名,不会把过期时间和当前时间做比较,也不会校验任何字段;成功解码出内容,不代表这个令牌已经通过验证、可以信任。

Sources: RFC 7519(JSON Web Token)

隐私与安全

• 在浏览器中计算 — 您输入的内容仅在本机设备上计算，不会发送到 utilduck 服务器。
• 加密连接 — 所有页面均通过 HTTPS 提供，传输过程中无法被读取。
• 不提供给第三方 — 您输入的内容不会传递给分析或广告服务。
• 不保存 — 计算结果不会保存到任何服务器，也无需注册账号。

最后更新: 2026-08-17