JWT 解码器
粘贴 JSON Web Token 即可解码 header 与 payload。仅做解码，不做签名验证。
什么是 JSON Web Token？
JSON Web Token（JWT，读作 "jot"）是 RFC 7519 定义的一种紧凑、URL 安全的声明（claims）传输格式。一个 JWT 由三段以点分隔的 Base64URL 串组成：声明签名算法的 header、承载实际声明的 payload、保护完整性的 signature。整体长度短到可以塞进 cookie、Authorization 头甚至查询字符串。
JWT 的解码完全是客户端操作：以点切分、对前两段做 Base64URL 解码、再当作 JSON 解析。本工具就是这么做的 —— 不会向任何服务器发送请求，也不会做签名验证，因为验证需要发行方的密钥或公钥，那只在服务端持有。把解码器当作调试辅助，而不是鉴权检查。
RFC 7519 定义了一组标准声明：iss（签发者）、sub（主题）、aud（受众）、exp（过期时间，Unix 时间戳）、nbf（生效时间）、iat（签发时间）、jti（token ID）。Auth0、AWS Cognito、Firebase、Supabase、Keycloak 等签发的 token 都遵循这一约定，并附加各自的扩展声明。
使用场景
- 查看认证服务在 Authorization 头中实际发送了什么。
- 请求被拒为未授权时，确认 exp 是否已过。
- 通过 sub 或 email 声明确认 token 属于哪个用户。
- 对比两个 token，找出 API 网关拒绝其中一个的原因。
- 在配置服务端验证器之前确认 header 中的签名算法（alg）。
最佳实践
- 永远不要在服务端用公钥验证签名之前信任一个 JWT。
- 保持 token 短期有效（分钟级），通过单独的 refresh token 续期。
- 不要在 payload 里放敏感数据 —— JWT 默认是签名而非加密。
- 服务端必须拒绝 alg = none 的 token，并仅接受期望的算法。
- 尽量把 JWT 存在 HttpOnly cookie 里以缓解 XSS，而不是 localStorage。
常见问题
本工具会验证签名吗？
不会。验证需要发行方的密钥或公钥，那只在服务端。本工具仅做解码，请勿据此做安全决策。
Payload 是加密的吗？
默认不是。JWT 是签名（JWS），而不是加密。任何人拿到 token 都能读 payload。需要保密时使用 JWE。
alg 字段是什么意思？
签名算法，例如 HS256（HMAC-SHA256）、RS256(RSA-SHA256)、ES256（ECDSA P-256）。
为什么有些 token 第三段是空的？
空签名意味着未签名 token（alg = none）。这非常危险，生产校验器绝不能接受。
怎么判断 token 是否已过期？
查看 exp 声明（Unix 秒）。解码器会显示解析后的过期时间，并在已过时给出警告。