JWT 解码器
粘贴一个 JWT,解码它的头部和负载,查看它何时过期,并检查标准声明字段。解码完全在你的浏览器中进行,所以生产环境的访问令牌永远不会离开你的机器。
- 文件永不离开你的设备
- 免费，无需注册
- 无水印
- 加载后可离线使用
如何JWT 解码器
- 1
粘贴你的令牌
粘贴完整的 JWT,包括两个点。它会随输入即时解码。
- 2
查看声明字段
头部和负载都会被格式化,过期时间和签发时间会显示成可读的日期。
- 3
复制你需要的内容
把解码后的负载以 JSON 形式复制出去,用在别处。
JWT 的三个部分到底分别是什么
一个 JSON Web Token 是三段用点连接起来的 Base64URL 编码片段:一个描述签名算法和令牌类型的头部,一个装着实际声明字段的负载——这个令牌标识的是谁、什么时候过期、被授予了什么权限——以及一个用密钥或私钥对前两段计算出来的签名。解码,也就是这个工具做的事,意味着把前两段 Base64URL 解码回可读的 JSON;对于第三段,它除了展示原始的编码值之外什么都不说,因为验证那个签名需要真正的签名密钥,而一个基于浏览器的工具永远不应该要求你把它粘贴进来。
解码与验证的这个区别,是理解一个 JWT 调试工具时最重要的一件事。解码告诉你一个令牌*声称*了什么;验证告诉你这些声明是否*可信*,方法是确认签名确实是由预期的签发方产生的。一个令牌可以完美地解码出来,显示一个声称拥有管理员权限的负载,而这整个令牌却是彻头彻尾伪造的——只要没有任何环节真正对照真实的签名密钥去检查这个签名。
为什么 JWT 不是存放敏感数据的安全场所
头部和负载是编码过的,不是加密的——Base64URL 是一种没有涉及任何密钥的可逆转换,所以任何拿到一个令牌的人,无论是通过截获网络流量、读取浏览器存储,还是被直接交到手上,都能不需要任何密钥就解码出负载、读到里面的每一个声明字段。这正是标准建议里要求把 JWT 负载限制在标识符和非敏感声明——一个用户 ID、一个角色、一个过期时间——绝不要把密码、信用卡号或任何其他机密数据直接放进令牌里的原因,因为这种令牌格式本身完全不提供任何机密性。
不用自己动手算,直接读懂 exp、iat 和 nbf
这几个标准的时间戳声明字段都是以 Unix 时间存储的——一个从 1970 年 1 月 1 日起计算的纯整数秒数——这对机器比较来说很高效,但对一个正用肉眼调试令牌的人来说完全看不懂。把 `1735689600` 手动换算成"2025 年 1 月 1 日 00:00:00 UTC",正是那种在时间压力下容易出错的小型算术,尤其是跨时区的时候。把这三个声明字段都渲染成实际的本地日期,并直接说明这个令牌当前是已过期、有效,还是尚未生效,把一次原本还需要额外手动计算的调试过程,变成了一个立即可读的答案。
常见问题
在这里粘贴一个生产环境的令牌安全吗?
比任何基于服务器的解码工具都更安全:令牌是在你的浏览器里被拆分和 Base64 解码的,不涉及任何网络请求。你可以断开网络连接来验证这一点——这个工具依然能正常工作。话虽如此,任何你粘贴到任何地方的令牌,都应该被当作需要轮换的令牌来对待。
这个工具会验证签名吗?
不会,而且是故意不做。验证需要签名密钥或公钥,而一个要求你粘贴签名密钥的浏览器工具,是一个不该被鼓励的坏习惯。验证应该放在你的后端进行,而不是放在一个网页里。
JWT 是加密的吗?
不是。头部和负载是 Base64URL 编码的,这是编码,不是加密——任何拿到这个令牌的人都能读到里面的每一个声明字段。永远不要把密码、银行卡号或个人数据放进 JWT 的负载里。
exp、iat 和 nbf 分别是什么意思?
它们都是以秒为单位的 Unix 时间戳。`exp` 是令牌过期的时间,`iat` 是令牌签发的时间,`nbf` 是这个令牌最早可以被接受的时间。这个工具会把这三者都渲染成本地日期,并告诉你这个令牌当前是否有效。
为什么我的令牌解码失败了?
一个 JWT 必须恰好由三段用点分隔的部分组成。常见的原因是复制时被截断了、留了一个前面的 "Bearer " 前缀没删掉,或者带上了一个来自 JSON 响应的包裹引号。