关于 JWT 解析器
调试登录态时最常见的情形是：浏览器里存着一个看起来像乱码的令牌，需要立刻知道它什么时候过期、属于哪个用户、带了哪些权限，而不想为此写一段脚本。JWT 解析工具把三段式令牌拆开并还原成可读的 JSON，用于排查「为什么明明登录了却提示无权限」「令牌是不是已经过期」「签发方与受众是否对得上」。 JWT 的结构是三段用点分隔的 Base64URL 字符串：头部声明算法与类型，载荷放具体声明（签发者、受众、过期时间、自定义字段），签名段由前两段按头声明的算法计算得出。解析只需做 Base64URL 解码与 JSON 解析，不涉及密钥，因此任何工具都能「解开」它——这正是关键认知：JWT 的载荷是编码而非加密，任何人都能读到里面的内容。 使用要点：先把 exp、iat、nbf 三个时间声明换算成本地时间再对比，注意它们是 Unix 秒而不是毫秒，直接当毫秒用会得到 1970 年；检查 iss 与 aud 是否与你的服务端配置一致，这是接入第三方登录时最常见的错误来源；alg 若为 none 表示未签名，服务端必须拒绝这种令牌，否则任何人都能伪造。调试期建议同时比对令牌头部声明的算法与服务端允许的算法列表。 边界与限制：解析成功不代表令牌有效。本工具不会、也不应该验证签名，因为没有密钥；签名验证必须在服务端用密钥或公钥完成，客户端校验签名在架构上毫无意义，因为攻击者可以同时改载荷与签名并通过你自己的校验逻辑。不要把「解出来的载荷」当作可信身份使用。另一个坑是时钟偏移：跨机房部署时服务器时间若相差数分钟，会让「刚签发的令牌立刻过期」或「已过期令牌仍被接受」。 数据与隐私：JWT 的载荷通常包含用户 ID、邮箱、角色，有时还带内部服务地址与权限清单；虽然它能被任何人解码，但把真实生产令牌粘贴到在线解析站点，等于把有效凭证交给对方（对方可直接用它调用你的接口）。本工具在浏览器内完成解码，不发送令牌；粘贴前建议先断开网络，并确认网络面板没有任何请求，排查完尽快在服务端轮换该令牌。
相关标准与常见变体值得一并了解。JWT 只是更大一组规范（JOSE）里的一环：JWS 是「签名」形态，也就是日常说的 JWT；JWE 是「加密」形态，载荷经过加密后不可读，因此用本工具去解 JWE 只会看到乱码，那不是工具出错而是设计如此。签名算法的选择上，HS 系列用同一个密钥签发与验证，适合单体服务；RS 与 ES 系列用私钥签发、公钥验证，适合让第三方验证而不交出签发能力，公钥通常通过 JWKS 端点以 JSON 形式发布。常见声明里除了 exp、iat、nbf，还有 sub（主体）、jti（唯一编号，可用于防止重放）、scope（权限范围）。排查时把这几项与你的服务端配置逐一对齐，绝大多数「令牌看起来正常却用不了」的问题都能定位到具体一项。
放到更大的图景里看，JWT 通常只是 OAuth 2.0 或 OpenID Connect 流程的一个产物：授权服务器签发，资源服务器校验。理解这条链路后就能判断问题出在哪一段——是授权服务器给的声明不对、还是资源服务器校验过严，比逐字盯着令牌本身更有效。
实现原理
令牌由三段点分字符串构成：头部声明算法与类型，载荷携带声明，签名段是对前两段按头部算法计算的结果。解析只做两件事——把每段按 URL 安全的编码还原，再把前两段当 JSON 读出来。因此解析**完全不需要密钥**，也就意味着任何人都能读到载荷内容；签名验证必须回到服务端用密钥完成。
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.x{"alg":"HS256"} / {"sub":"123"}（签名段无法在无密钥时验证）使用方法
- 打开 JWT 解析工具
- 将完整的 JWT 字符串粘贴到输入框
- 自动解码 Header 和 Payload，以 JSON 格式展示
- 查看过期时间、签发时间等关键信息
- 输入密钥验证签名（仅支持 HS256/384/512）
使用场景
- 调试登录态问题 — 用户反馈"登录失效"时，从浏览器拷贝 token 解析过期时间和声明字段。
- 检查 OAuth/OIDC 流程 — 查看 access_token 和 id_token 的 claims（sub、aud、iss 等）。
- 校验 token 结构 — 判断后端发的 token 是否包含预期的自定义字段（如 user_id、role）。
- 理解第三方 SSO — 研究 Auth0、Firebase、Okta 等 IdP 颁发的 token 内容。
- 排查 401 错误 — 快速看出 token 是否已过期（exp 字段）或还未生效（nbf 字段）。
常见问题
JWT 是加密的吗？
不是。JWT 默认只是 Base64URL 编码（不是加密），任何人拿到 token 都能解码看到 payload。需要保密的内容请用 JWE 或不要放入 JWT。
本工具会校验签名吗？
不会。校验签名需要服务端的密钥或公钥，本工具仅做解码展示。生产环境请在后端用 jose、jsonwebtoken 等库验证。
JWT 怎么手动失效？
无法在不维护服务端黑名单的情况下提前失效。这是 JWT 的固有缺陷——所以 access_token 通常只设几分钟有效期，配合 refresh_token 使用。
JWT 比 session cookie 更安全吗？
不一定。JWT 适合无状态分布式场景，但 session cookie 配合 HttpOnly+Secure 也很安全。选哪种取决于架构，不是安全等级问题。
为什么我的 JWT 太长了？
payload 越多 token 越大。建议只放必要字段（sub、exp、aud、role）。每个 HTTP 请求都要带 token，过大会浪费带宽。
我的 access token 为什么过期这么快？
短生命周期（几分钟到一小时）是业界推荐设计，不是配置错误：它把 token 泄露后的有效窗口压到最小，再靠 refresh token 在临期前静默刷新维持长会话。若觉得太快，先检查签发端 exp 设置；前端应监听 401 或在 exp 之前提前刷新，而不是逼用户频繁重新登录。同时确认后端时钟（NTP）与签发时间一致——时间漂移会让 token 被立即判为过期。
payload 里到底该放什么、不该放什么？
只放必要且尽量小的声明：sub、exp、iat、aud、iss、role 等。不要放密码、手机号、身份证号等敏感数据——JWT 默认只是 Base64URL 编码，任何人拿到都能原样读出。能被用户侧改动的字段（如价格、权限）更不该放，必须以后端为准并在服务端二次校验。若确需保密，改用 JWE 加密，或用服务端 session 存放敏感字段而不是塞进 token。
解析 JWT 会验证签名吗？
不会——解码只是 Base64URL 展开 payload，任何人都能构造。验证签名需要服务端的密钥/公钥。所以「解析成功」绝不等于「token 有效」；校验逻辑必须放在服务端，前端解析仅用于读取过期时间等非敏感信息。