JWT 解码器

一个 JSON Web Token 看起来像一串无法辨认的乱码，但它其实只是三段由点号连接的 Base64URL 编码内容：Header、Payload 和 Signature。解码 Header 和 Payload 根本算不上加密 —— 任何拿到令牌的人都能读出里面的声明内容，这也正是为什么敏感数据永远不应该被塞进 JWT 的 Payload 里。真正的问题在于，人们需要检查的令牌很少是可以随意丢弃的测试数据。它们往往是生产环境应用中正在使用的会话令牌、API 访问令牌，或是调试时直接从浏览器开发者工具里复制出来的登录 Cookie —— 这是一份真实的凭证，一旦落入他人之手，就意味着真实的访问权限。把它粘贴到一个来路不明的网站上，等于把你的会话拱手交给一个你完全不了解的服务器。

这个工具不会这样做。当你粘贴令牌的那一刻起，Header 和 Payload 就由运行在你浏览器中的纯 JavaScript 完成解码 —— 按点号拆分、进行 Base64URL 解码、解析为 JSON —— 整个过程没有任何数据被发送出去。签名验证的原理也是一样，依靠现代浏览器内置的 Web Crypto API（`SubtleCrypto`）：HMAC 算法（HS256、HS384、HS512）会根据你输入的密钥进行验证，RSA 算法（RS256、RS384、RS512）则根据你粘贴的 PEM 格式公钥进行验证。无论是密钥本身还是验证过程，都只停留在这个标签页内 —— 刷新页面后，令牌、密钥、公钥全部消失，不留痕迹。

粘贴一个令牌，即可看到其 Header 和 Payload 被格式化清晰地展示出来，同时附带标准的 `exp`、`iat`、`nbf` 声明并转换为易读的日期格式；如果令牌的 `exp` 已经过去，还会显示醒目的“已过期”标签 —— 这在核实“我莫名其妙被登出了”这类问题反馈时非常实用，往往一看便知只是令牌过期而已。如果算法是 HS256/384/512 或 RS256/384/512，输入对应的密钥或公钥即可检查签名是真实有效还是已被篡改。至于这个范围之外的算法（比如 ES256，或未签名的 `none`），解码依然正常，只是不会提供验证功能，以免给出虚假的验证结果。对本地开发而言，可编辑的 Header/Payload 输入框还能让你调整某个声明 —— 比如改一个用户 ID 或角色 —— 然后用测试服务器所使用的同一个 HS256 密钥重新签名，这是在不搭建完整登录流程的情况下测试授权逻辑的常见做法。

由于 JWT 的 Payload 解码后就是普通、可读的 JSON，如果需要更细致地查看某个嵌套很深的声明，搭配 JSON Formatter & Validator 工具会非常顺手。这里也提醒一句安全上的常识：既然解码完全不需要任何密钥，那么任何令牌在你检查完之后都应被当作敏感信息处理；如果不确定它在到达这里之前还被粘贴到过哪些地方，而它原本只该是短期有效的凭证，那就应该及时轮换相关的凭证。