JWT 解码

解码 JWT 的 Header/Payload，标注过期时间，本地不上传

关于JWT 解码

JWT 由三段 Base64URL 组成：头部声明算法，载荷携带业务信息（用户 ID、权限、过期时间），签名用于验证来源。解码只是把前两段还原成 JSON，任何人都能做——所以解码成功不代表令牌有效，签名校验必须在服务端完成。

使用步骤

1. 复制完整的 JWT（eyJ 开头的三段式字符串）
2. 粘贴后自动分开显示 Header / Payload / Signature
3. 重点核对 exp（过期时间）、iat（签发时间）与 scope 权限字段
4. 过期或权限不符时联系签发方重新获取，不要手工改内容

常见错误

把解码当验签

解码零门槛，任何人都能构造一个能解码的假令牌。判断令牌可信度只能靠服务端验签。

在 JWT 里放敏感信息

Payload 只是 Base64，不是加密。手机号、内部标识这类信息不要放进去，只放非敏感的身份声明。

过期时间不看时区

exp 是秒级 UTC 时间戳，和本地时间对比前先换算。联调时“莫名 401”多半是这里差了几小时。

常见问题

解码出来的内容能直接用来判断权限吗？

不能。攻击者可以伪造任意载荷，只有服务端验签通过后的内容才可信。前端解码仅用于调试。

exp 是秒还是毫秒？

JWT 规范的 exp/iat/nbf 都是秒级时间戳。看到 10 位数字是正常的，13 位通常是实现方用了毫秒，需与签发方确认。

解码和验签有什么区别？

解码只是把 Base64URL 还原成 JSON，谁都能做，不需要密钥；验签是验证这段内容确实由持有私钥的一方签发、且没被改过。很多「JWT 漏洞」的根源就是把解码结果当成可信身份——签名没验，内容就是可以随便编的。

alg:none 是什么漏洞？

JWT 头部有个 alg 字段声明签名算法。早期库会信任这个字段，攻击者把它改成 none 并去掉签名，服务端就当作「无需验证」放行。正确做法是服务端固定允许的算法列表，绝不采信头部声明的值。

token 会被发到服务器吗？

不会，解码在浏览器里完成。但注意别在公共电脑上粘贴生产环境的 token——它本身就是凭证，任何人拿到就等价于拿到那个身份，有效期结束前一直有效。

来源：内置实现 (Base64URL) · License: MIT · 分类：开发

相关阅读

• 二维码生成 —— 把文本/网址变成二维码，可下载 PNG
• 哈希计算 —— SHA-256/384/512 哈希，基于 WebCrypto 安全实现
• UUID / ULID 生成 —— UUID v4、ULID、Nano ID 批量生成，可作数据库主键
• DevDocs —— 同类第三方工具（官方在线版）
• Prettier Playground —— 同类第三方工具（官方在线版）
• 前端调试工具包 —— 专题工具包
• 接口联调试探 —— 专题工具包
• 隐私与安全工具箱 —— 专题工具包
• 全部开发类工具 —— 按分类浏览

← 返回 ToolHub 全部工具