JWT 解析工具 在浏览器本地解码 JSON Web Token 的三个部分（header / payload / signature），展示算法、签发方、过期时间等关键 claim，不上传 token，不校验签名。
JWT 结构：三段用 . 分隔的 base64url 字符串 —— <header>.<payload>.<signature>。
| 段 | 内容 | 是否加密 |
|---|---|---|
| header | 算法 alg、类型 typ | 否，base64url 编码，秒解 |
| payload | 业务 claim（用户 ID、角色、时效等） | 否，base64url 编码，秒解 |
| signature | 前两段的 HMAC / RSA / ECDSA 签名 | 非加密，是防篡改凭证 |
签名 ≠ 加密：JWT 默认不加密，payload 是公开可读的，任何人都能解。签名只保证 token 内容未被改过。要加密 payload 用 JWE（JSON Web Encryption），那是另一套规范，用得相对少。
常见 claim 速记：
exp（Expiration）：过期时间，Unix 秒iat（Issued At）：签发时间nbf（Not Before）：生效时间（到点才有效）iss（Issuer）：签发方，如 https://auth.example.comsub（Subject）：主体标识，一般是用户 IDaud（Audience）：预期接收方工具本地运行，粘贴的 token 不上传，解析结果不记录——放心粘生产环境的调试 token。
不会。签名校验需要服务端私钥或公钥，本工具只做解码展示，不承诺 token 是"真的"。要验签请在后端或 jwt.io 这类专用工具里做。重点提醒：JWT 的 header/payload 任何人都能解，千万别在 payload 里放密码、纯数字短 ID 等敏感内容。
两种常见原因：一是前端只检查本地时间，本地钟不准就会误判；二是后端做了 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 等，按项目约定，工具会原样展示。
签名是 `HMAC(header+payload, secret)` 或 `RSA(header+payload, privateKey)`，payload 里的 `iat`（签发时间）每次登录都不同，导致整个签名段不同。所以同一用户两次登录拿到的 token 签名必然不同——这是正常的，不代表后端在乱签。
要。`Bearer ` 是 HTTP Authorization 请求头的类型前缀（RFC 6750），不是 token 本身的一部分。完整请求头形如 `Authorization: Bearer eyJ...`，粘进解析工具前请去掉 `Bearer ` 这个前缀（含尾部空格），否则第一段会多出 `Bearer eyJ` 解码失败。
JWT：无状态，服务端不存，信息全在 token 里，天生适合分布式；缺点是签出去就无法单点吊销（要配合黑名单或缩短 exp）。Session：状态在服务端（redis/db），cookie 里只有 sessionId，吊销简单但每次请求都要查存储。大型系统常见组合：短 exp 的 JWT + 服务端 refresh token 白名单。