JWT 解析工具 在浏览器本地解码 JSON Web Token 的三个部分（header / payload / signature），展示算法、签发方、过期时间等关键 claim，不上传 token，也不做验签。
三段用 . 分隔的 base64url 字符串 —— <header>.<payload>.<signature>。
| 段 | 内容 | 是否加密 |
|---|---|---|
| header | 算法 alg、类型 typ | 否，base64url 编码，秒解 |
| payload | 业务 claim（用户 ID、角色、时效等） | 否，base64url 编码，秒解 |
| signature | 前两段的 HMAC / RSA / ECDSA 签名 | 非加密，是防篡改凭证 |
JWT 默认不加密，payload 是公开可读的，任何人都能解。签名只保证 token 内容未被改过。要加密 payload 用 JWE（JSON Web Encryption），那是另一套规范，用得相对少。重要：千万别在 payload 里放密码、银行卡号等敏感内容。
exp（Expiration）— 过期时间，Unix 秒iat（Issued At）— 签发时间nbf（Not Before）— 生效时间（到点才有效）iss（Issuer）— 签发方，如 https://auth.example.comsub（Subject）— 主体标识，一般是用户 IDaud（Audience）— 预期接收方工具在浏览器本地解码，粘贴的 token 不上传，解析结果也不会被本站保存。即便如此，生产 token 仍可能包含敏感业务声明，调试前最好确认最小暴露范围，并优先使用短期、低权限样本。
不会。本工具只做解码展示，不承诺 token 一定可信。要验签请用你自己的服务端逻辑，或直接使用本站的 JWT 验签工具。重点提醒：JWT 的 header / payload 默认只是可读编码，不要把密码、银行卡号、完整证件号等敏感内容直接放进 payload。
两种常见原因：一是前端只检查本地时间，本地钟不准就会误判；二是后端做了 refresh token 自动续签，exp 只是 access token 的过期，refresh token 还没过期时仍能换一张新的。建议看请求头里每次实际发送的 token 是哪张，别只盯着 localStorage 里那张看。
RFC 7519 标准 claim：iss 签发方、sub 用户标识、aud 目标受众、exp 过期时间戳（秒）、iat 签发时间、nbf 生效时间（到点才有效）、jti token 唯一 ID 用于黑名单。自定义 claim：role、scope、tenantId、deviceId 等，按项目约定，工具会原样展示。
签名通常是对 header.payload 做 JWS 签名或 MAC；只要 iat、exp、jti 等任一字段变了，最后一段就会不同。所以同一用户两次登录拿到的 token 经常不同，这很正常。
Bearer 开头，要去掉吗？要。Bearer 是 HTTP Authorization 请求头的类型前缀（RFC 6750），不是 token 本身的一部分。完整请求头形如 Authorization: Bearer eyJ...，粘进解析工具前请去掉 Bearer 这个前缀（含尾部空格），否则第一段会多出 Bearer eyJ 解码失败。
JWT 更适合把声明随请求一起带走；Session 更适合把状态留在服务端集中控制。JWT 不等于“天然更高级”，Session 也不等于“不能分布式”。实际取舍要看你的吊销需求、跨服务验证需求和现有基础设施。