JWT 解码

调试登录失败时，先看清 Token 里写了什么、有没有过期。解码只是 Base64URL，谁拿到这段字符串都能读。可读不等于可信。

接口突然 401，你只想知道这枚 Bearer 里的 sub、exp 到底写了什么——又担心随手贴到某个「在线解码」会被记日志。这是看内容，不是改权限、更不是破解密钥。

JWT 常见形态是三段：header.payload.signature。本页对前两段做 Base64URL 解码并格式化 JSON。第三段签名原样摆在那里，不会拿去验。BeJSON 一类页面常把「JWT 加解密」写在一起；这里把话说死：解码 ≠ 加密，更 ≠ 验签。

示例（无签名，仅供理解结构）：

eyJhbGciOiJub25lIn0.eyJzdWIiOiJ0b29sYXRsYXMiLCJ0b29sIjoiand0LWRlY29kZXIifQ.

什么时候用

• 本地或测试环境，核对 claims 有没有写错受众、角色。
• 看 exp / nbf 是否已经过期或尚未生效。
• 确认 alg 是不是 none，或是否与文档声明一致。

不要用这一页： 伪造管理员 Token、爆破 HS256 密钥、解密 JWE。那些既做不到，也不该做。

怎么用

1. 整段粘贴，可带或不带 Bearer 前缀。
2. 阅读 header 与 payload。把时间字段拿到Unix 时间戳转换对照。
3. 看完关掉标签页。不要把生产 Token 存进文档或截图发群。

只是普通 Base64 字符串，用Base64 编码与解码。要把接口返回的 JSON 排版，用JSON 格式化与校验。

限制

• 不做签名校验，也不生成新 Token。
• 不保证把所有时间字段都「人性化」成倒计时。
• 畸形、缺少点号的字符串会失败。
• jwt.io 是行业里的品牌调试器；本页不靠打它的名字抢标题。

中文开发工具箱几乎都在讲「纯前端」。真正要记住的是：谁都能读 payload，只有密钥持有者能证明它没被改过。