JWT 解码
解码 JWT 看 header、声明与是否过期，或把自己写的 header 与 payload 编成一个未签名的 token。两者都在本地完成，从不索要密钥。
在浏览器里本地解码。本工具从不向你索要密钥，也从不验证签名 —— 解开一个 token 不等于可以信任它。
两个框都必须填 JSON 对象。产物没有签名 —— 要签名就在密钥本来就所在的地方补上。
什么时候会用到
- 请求返回 401，你要分清是 token 过期了、还没生效，还是别人签的。
- 调试对接时想直接看到 exp 和 iat 对应的人类日期，而不是两个十位数。
- token 看起来可疑，你想先读它的 alg 和声明，再决定要不要发给别人。
- 需要确认第三方登录到底往 payload 里塞了什么 —— 邮箱、角色、租户 id。
别的 JWT 解码器差在哪里
很多解码器会向你要密钥，好替你做「验证」。把生产环境的签名密钥粘进一个网页，是你能对 JWT 做的最糟的一件事，而邀请你这么做的工具并没有在帮你。
有些工具只把 JSON 打出来，压根不碰 exp，把「把秒数换算成时间」这一步留给你 —— 而这一步恰恰是判断过期时最容易算错的。
还有的在只是解开了 base64 之后就亮一个绿色的「有效」。一个被解析的 token 什么都证明不了，能证明的只有验签，而验签需要密钥。
常见问题
这个工具验证签名吗？
不验证，也永远不会。验签需要签名密钥（HS 系列）或公钥（RS 与 ES 系列），而让你把其中任何一个粘进网页，会造成比你来这里解决的问题更严重的问题。本工具只负责解码和报告，验签必须在密钥本来就所在的地方完成。
把真实的 token 粘进来安全吗？
解码在浏览器里完成，没有上传。但 JWT 本身就是凭证：拿到它的人可以在过期前冒充那个用户。所以把 token 粘进任何页面（包括这里）都应当按粘贴密码的标准对待，能换测试 token 就换测试 token。
exp、iat、nbf 分别是什么？
exp 是 token 失效的时刻，iat 是签发时刻，nbf 是它最早可以使用的时刻，三者都是 Unix 秒。只有 exp 意味着过期；nbf 在未来意味着「还没生效」，这是另一种失败。
为什么我的 token 没有 exp？
因为签发方没有设置。这样的 token 不会自己过期 —— 它会一直有效，直到服务器另有决定（吊销名单、短会话存储，或者干脆什么都没有）。如果你就是签发方，这通常是缺陷而不是设计。