跳转至

JWT 解码器

纯前端 · 只解码不验签：粘贴 JWT，立即拆开三段并格式化。数据不出浏览器，不联网、不记录，也不会帮你验签。

怎么用

把一段 JWT（形如 xxxxx.yyyyy.zzzzz，用两个点号分三段）粘进下面，点 解码，工具会展示 header、payload 的格式化 JSON，并把 exp / iat / nbf 这类时间字段转成可读日期。

JWT 到底是什么

JSON Web Token 是一种把「声明（claims）」用 JSON 承载、再加签名的令牌格式，广泛用于登录态、API 鉴权、单点登录。它长这样：

header.payload.signature

三段用点号连接：

  • header：元数据，通常是 { "alg": "HS256", "typ": "JWT" }，说明签名算法和类型。
  • payload：真正的业务声明，比如用户 ID、角色、过期时间。
  • signature：用密钥对「header.payload」算出的签名，用来保证前两段没被篡改。

关键点：前两段只是 base64url 编码，不是加密。任何人拿到令牌都能解码读内容，只有签名这一步才需要密钥。

常见字段速查

字段 含义 说明
iss 签发者 谁发的这个令牌
sub 主体 令牌代表的是谁（用户 ID）
aud 受众 令牌发给哪个服务用
exp 过期时间 Unix 秒，过了就失效
iat 签发时间 Unix 秒，什么时候发的
nbf 生效时间 Unix 秒，在此之前不可用
jti 唯一 ID 用于防重放

这些字段都是「约定俗成」的标准注册声明，具体业务还会往 payload 里塞自定义字段（如 role、tenant）。解码后对照这张表，令牌在说什么一目了然。

解码 ≠ 验签，这条必须记住

这是 JWT 最容易误用的地方，单独强调：

  • 解码是公开的：base64url 解码不消耗任何密钥，等于把内容摊开给你看，目的是排查和阅读。
  • 验签才是信任：签名验证需要密钥，确认「内容没被改、确实是签发者发的」。这一步只能在持有密钥的服务端做。
  • 所以：本工具解码出来的 payload 哪怕看起来完全正常，也不能当信任依据。攻击者改了 payload 再重新 base64url 编码，解码出来照样「合法」。信任永远建立在服务端验签之上。

几个真实的安全坑位

alg=none 攻击：部分库允许把 alg 设为 none，相当于去掉签名。攻击者可把 alg 改成 none、删掉签名、随意改 payload，一些配置不当的服务端会照单全收。健壮实现必须显式拒绝 none，并固定预期算法，不信任令牌自带的 alg 字段。

算法混淆（RS256 ↔ HS256）：RS256 用非对称密钥（公钥验签），HS256 用对称密钥（同一密钥签名验签）。如果服务端预期 RS256 却允许 HS256，攻击者可拿公钥当 HMAC 密钥去伪造签名。服务端要锁定算法，别让令牌自述算法。

exp 是 Unix 秒，不是毫秒：不少人把毫秒时间戳填进 exp，导致令牌立刻过期或永不过期。解码时如果发现过期时间离谱（比如 1970 年或几百年后），先怀疑单位搞错。

敏感信息别塞 payload：因为 payload 只是编码不加密，令牌里放用户邮箱、权限细节没问题（接收方本就该能看到），但绝不要放密码、密钥、身份证号这类机密——任何拿到令牌的人都能读。

什么时候用这个工具

  • 联调接口时，快速看清楚后端发的令牌里到底有哪些声明、什么时候过期；
  • 排查「为什么登录后还是 401」：先解出来看 exp 是不是早过了、aud 对不对；
  • 在日志里定位某次请求携带的 sub / jti，做审计回溯。

它帮你「看懂」令牌，但请始终把「是否可信」的判断留给服务端验签。

一个解码示例

拿一个真实形态的令牌举例（已截断签名，仅示意结构）：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMH0.SflKx...

解码后：

  • Header：{ "alg": "HS256", "typ": "JWT" } —— 用的是对称签名。
  • Payload：{ "sub": "user-123", "role": "admin", "exp": 1700000000 } —— exp 换算成可读时间后，你能立刻判断这条令牌是否已过期。
  • Signature：一段看不懂的签名串，本工具不解析也不验证。

这种「先解出来看 exp 和 role」的动作，就是你日常定位鉴权问题最高频的用法。

JWT 在运维架构里的位置

  • API 网关：网关校验 JWT 签名，决定是否放行、把 sub / role 注入下游请求头。解码工具帮你确认网关到底看到了什么声明。
  • 微服务间调用：服务 A 调服务 B，常把 JWT 透传，B 自己验签取声明，省去每次查中心会话库。
  • 单点登录（SSO）：一次登录拿到 JWT，多个系统共用，减少重复登录。
  • 移动端 / SPA：前端把令牌存本地（注意存哪、防 XSS），每次请求带上。
方案 状态 优点 缺点
Session Cookie 服务端有状态 可随时吊销、改了立刻生效 要共享会话存储，扩展开销大
不透明令牌 服务端查库 可控、可吊销 每次都要查，延迟高
JWT 无状态 自包含、不用查库、易扩展 难即时吊销、payload 不加密

选哪个看场景：要强吊销（如风控紧急踢人）就别用纯 JWT；要水平扩展、跨服务自包含声明，JWT 很合适。很多系统折中：JWT 配短过期 + 刷新令牌。

服务端怎么验签（本工具不做的事）

解码只把内容摊开，验签才是信任的闭环。以 HS256 为例，服务端拿密钥对 header.payload 做 HMAC-SHA256，把结果和令牌里的 signature 比对，一致才信。RS256 则用私钥签名、公钥验签。这一步必须在服务端、且用服务端持有的密钥完成——正因为需要密钥，浏览器里的纯前端工具永远做不到，所以它只会解码。

顺带提醒：验签时务必固定算法（见上文 alg=none / 算法混淆坑），不要信任令牌自带的 alg 字段。

刷新令牌怎么配合

JWT 一般设较短的 exp（几分钟到几小时），降低泄露后被滥用的窗口。过期后用刷新令牌换新的访问令牌。刷新令牌通常另存、可吊销、生命周期更长。排查「频繁掉登录」时，先解访问令牌看 exp 是不是太短、刷新链路有没有断；本工具看的始终是访问令牌本身。

相关教程