JWT 在线解码器
免费的 JWT（JSON Web Token）在线解码工具，可视化解析 Header、Payload、Signature 三段，自动识别 exp/nbf/iat 时间戳并判断 Token 是否过期。完全在浏览器本地解码，Token 不会发送到服务器。
最后更新：
什么是 JWT
JWT（JSON Web Token，RFC 7519）是一种紧凑的、自包含的身份认证令牌格式。它把 Header（算法与类型）和 Payload（声明信息） 两段 JSON 用 Base64URL 编码后用 . 拼起来，再用密钥/私钥对前两段签名， 得到第三段 Signature，最终形式为：
<base64url(header)>.<base64url(payload)>.<base64url(signature)>
因为签名是用密钥生成的，攻击者无法伪造一个有效的 JWT；服务端拿到 Token 后用密钥（HMAC） 或公钥（RSA/ECDSA）验证签名即可信任 Payload 内容，不需要查数据库——这就是它"无状态"的来源。
标准 Claim 字段
| 字段 | 英文全称 | 含义 |
|---|---|---|
| iss | Issuer | 签发方标识，通常是认证服务的域名 |
| sub | Subject | 主体，通常是用户 ID 或资源标识 |
| aud | Audience | 受众，Token 给哪个服务用，验证时应严格匹配 |
| exp | Expiration Time | 过期时间（Unix 秒），过期后必须拒绝 |
| nbf | Not Before | 生效时间，之前不可用 |
| iat | Issued At | 签发时刻 |
| jti | JWT ID | Token 唯一标识，常用于黑名单/防重放 |
JWT 安全易错点
- 不要把敏感信息塞进 Payload：Payload 是明文 Base64URL， 任何人都可读，不要放密码、密钥、身份证号。
- 绝不信任 header 里的 alg：服务端必须强制使用预设算法（如 RS256）， 不能用
alg=none、不能允许"算法切换"。 - HMAC 密钥够强：HS256 的密钥应至少 32 字节、且来自安全随机源； 否则会被暴力破解。
- 始终校验 exp、nbf、aud、iss：很多漏洞都是因为只验签名不校验声明。
- Refresh Token 单独存储：access_token 短期、refresh_token 长期， refresh 必须放 HttpOnly Cookie 或服务器侧白名单。
- 支持撤销：JWT 默认不可撤销，需要时建一个 jti 黑名单 或缩短 access_token TTL（如 15 分钟）。
常见问题
JWT 解码工具会上传我的 Token 吗？安全吗？
本工具的所有解码逻辑都运行在浏览器内（前端 JavaScript），Token 不会发送到任何服务器。但请注意：JWT 本身是「编码」不是「加密」，任何拿到 Token 字符串的人都可以解码看到 Payload 内容。所以生产 Token 不要贴到任何在线工具/聊天/截图里。如有疑虑，可断网测试或自建。
为什么这里看不到签名验证（Verify Signature）？
签名验证需要密钥：HMAC 算法（HS256 等）需要 secret，RSA/ECDSA（RS256/ES256）需要公钥。把密钥粘到任何在线工具都有泄露风险，所以本工具刻意不提供。线上验证请用后端库：Node.js 的 jose、jsonwebtoken；Java 的 jjwt；Python 的 PyJWT；Go 的 golang-jwt。
Token 显示「已过期」但服务还能用，是怎么回事？
可能原因：1) 服务端时钟与你本地时钟不同步（NTP 偏差）；2) 服务端配置了 leeway（容差，比如允许过期前后 60 秒）；3) 你看的是旧的 access_token，服务实际接受的是新的；4) 中间网关用了 refresh_token 静默刷新。检查这些前请先确认本地系统时间正确。
JWT 和 Session Cookie 应该选哪个？
Session（服务端存储 + Cookie）：状态可即时撤销，适合 Web 单体后台；JWT（无状态）：跨服务/跨域方便、节省 Redis 查询，但很难「即时让一个 Token 失效」。建议：1) 短期 access_token（5-30 分钟）+ 长期 refresh_token；2) 真要支持登出/封禁，要么后端维护一个黑名单，要么干脆别用 JWT。
alg=none 是什么？为什么是安全坑？
"alg": "none" 表示这个 JWT 不带签名，曾经的 jwt 库会"按 header 说的算法验证"，攻击者直接把 alg 改成 none、把 signature 留空，库就放行了——这是著名的 CVE-2015-9235 系列漏洞。现代库默认拒绝 alg=none，但自研代码一定要硬编码允许的算法白名单，不要信任 header 里的 alg。
Payload 可以放敏感信息（如密码、身份证号）吗？
绝对不能。JWT 的 Payload 是 Base64URL 编码的明文，任何人都能解码。Payload 里只放：用户 ID、角色、过期时间这类业务标识；绝不要放密码、密钥、身份证、银行卡、个人隐私字段。如确实需要加密的 Token，请用 JWE（JSON Web Encryption），它是 JWT 的加密变体。