JWT 解码器 (头部、载荷、签名、过期)

粘贴 JWT 即时将头部和载荷解码为 JSON。识别标准声明 (iat、exp、nbf) 并将 Unix 时间戳转换为 ISO 8601。标记已过期或未生效的 token。

JWT 令牌

在浏览器内完成解码,token 不会通过网络传输。

头部

{
  "alg": "HS256",
  "typ": "JWT"
}

载荷

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1730000000,
  "exp": 4886000000
}

存在签名: ✓
签发时间 (iat): 2024-10-27T03:33:20.000Z
过期时间 (exp): 2124-10-30T22:13:20.000Z

工作原理

JWT 的结构

JWT 是用点号连接的三段 Base64url 编码: header.payload.signature。每段是为 URL 安全传输而编码的 JSON。头部声明签名算法,载荷携带声明 (主体、过期、自定义数据),签名让接收方在持有密钥时验证完整性。

本解码器只读前两段。签名是第三段,但验证需要密钥/公钥——这是单独操作,本工具不执行。

值得了解的标准声明

iss (issuer): 签发者。iat (issued at): 签发时间,Unix 时间戳。exp (expiry): 失效时间,Unix。nbf (not before): 最早可被接受的时间。sub (subject): token 代表的实体,通常用户 ID。aud (audience): token 面向的服务,通常服务 URL。

并非全部必需,最小 JWT 常仅包含 sub + iat + exp。自定义声明是其他任意键,与标准声明并列在载荷中。

解码 ≠ 验证

任何人都能解码 JWT —— 头部和载荷只是 Base64 编码的 JSON。所以「不要把秘密放在载荷」: 等同公开信息。

验证意味着用密钥 (HMAC) 或公钥 (RSA/ECDSA) 校验签名。未经验证,载荷中任何声明都不可信 —— 攻击者可伪造任意载荷。

用本工具调试时检查 token,生产环境务必用服务器端 JWT 库验证。

常见问题

›可以验证签名吗?

不能 —— 验证需要密钥或公钥,这些不应离开可信环境。请使用服务器端 JWT 库 (Node 的 jsonwebtoken、Python 的 PyJWT 等)。

›Token 会上传吗?

永不。解码本地完成,我们没有接收 token 的服务器端口。

›为何 token 「无效」?

常见原因: 复制粘贴混入/丢失空白、不足三段、某段为非法 Base64url。修剪后重试。

›Base64url 和 Base64 的区别?

Base64url 把 '+' 换 '-'、'/' 换 '_',去掉末尾 '=',让编码字符串在 URL 和 HTTP 头中安全传输。JWT 始终用 Base64url。

›为何 Unicode 载荷显示乱码?

本工具按 UTF-8 解码 (标准做法)。如载荷用其他编码,JSON.parse 会失败。大多数 JWT 签发者正确使用 UTF-8。

›HS256 安全吗?

若密钥足够长 (≥256 位) 且保密,则安全。常见 HS256 漏洞是弱密钥和接受 alg='none'。使用 ≥32 字符随机密钥,显式拒绝 'none'。

›为何用 RS256 优于 HS256?

RS256 (非对称 RSA) 可发布验证用公钥同时保密签名密钥。HS256 (对称 HMAC) 需与每个验证者共享密钥。多服务架构下 RS256 更安全。

›可以解码巨大 token 吗?

实际上限约 10 MB,超过浏览器会变慢。JWT 通常小于 4 KB。如更大,考虑是否在声明里塞了过多内容。