⭐ 觉得好用?收藏备用,下次直接打开 ✨ 开通会员去广告 · 更多权益即将开放 ☕ 支持作者

粘贴JWT,查看载荷内容、签发时间和过期时间。

输入 JWT Token

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 签名非加密,是防篡改凭证

解码与验签

解码成功只说明内容可以被读取,不能证明签名有效。页面根据本机时间显示 exp、iat、nbf,时间提示也不能替代服务端验证。需要检查签名时,请使用 JWT 验签工具,并按业务规则校验签发方和受众等声明。

签名 ≠ 加密

JWT 默认不加密,payload 是公开可读的,任何人都能解。签名只保证 token 内容未被改过。要加密 payload 用 JWE(JSON Web Encryption),那是另一套规范,用得相对少。重要:千万别在 payload 里放密码、银行卡号等敏感内容。

常见 claim 速记

  • exp(Expiration)— 过期时间,Unix 秒
  • iat(Issued At)— 签发时间
  • nbf(Not Before)— 生效时间(到点才有效)
  • iss(Issuer)— 签发方,如 https://auth.example.com
  • sub(Subject)— 主体标识,一般是用户 ID
  • aud(Audience)— 预期接收方

本地运行

工具在浏览器本地解码,粘贴的 token 不上传,解析结果也不会被本站保存。即便如此,生产 token 仍可能包含敏感业务声明,调试前最好确认最小暴露范围,并优先使用短期、低权限样本。

📍使用场景

  • 排查登录态失效粘贴前端 localStorage 里的 token,秒看 exp 是否过期、iss 是不是预期签发方。
  • 调试权限与角色看 payload 里的 role / scope / permissions 字段,判断接口 403 是不是角色缺失。
  • 对接第三方登录OAuth / OIDC 回调拿到的 id_token 直接粘进来,快速对齐文档里应有的 claim。

❓常见问题

工具会校验签名吗?

不会。本工具只做解码展示,不承诺 token 一定可信。要验签请用你自己的服务端逻辑,或使用本站的 JWT 验签工具。重点提醒:JWT 的 header / payload 默认只是可读编码,不要把密码、银行卡号、完整证件号等敏感内容直接放进 payload。

为什么我的 token 过期了但前端还能用?

两种常见原因:一是前端只检查本地时间,本地钟不准就会误判;二是后端做了 refresh token 自动续签,exp 只是 access token 的过期,refresh token 还没过期时仍能换一张新的。建议看请求头里每次实际发送的 token 是哪张,别只盯着 localStorage 里那张看。

常见的 claim 都有什么含义?

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 经常不同,这很正常。

我看到 token 以 Bearer 开头,要去掉吗?

要。Bearer 是 HTTP Authorization 请求头的类型前缀(RFC 6750),不是 token 本身的一部分。完整请求头形如 Authorization: Bearer eyJ...,粘进解析工具前请去掉 Bearer 这个前缀(含尾部空格),否则第一段会多出 Bearer eyJ 解码失败。

JWT 和 session cookie 有什么区别?

JWT 更适合把声明随请求一起带走;Session 更适合把状态留在服务端集中控制。JWT 不等于“天然更高级”,Session 也不等于“不能分布式”。实际取舍要看你的吊销需求、跨服务验证需求和现有基础设施。