JWT 解码器

Q: 解码失败提示格式错误怎么办？

检查是否复制完整：JWT 必须有三段、以两个点分隔；复制时常会漏掉首尾字符或带入空格换行。

Q: 工具能验证签名吗？

不能也不应该——验证 HS256 签名需要服务端密钥，RS256 需要公钥；把密钥粘贴到网页工具里是危险行为。本工具只做解码。

Q: 为什么我的 Token 解出来 iat 是 1970 年？

大概率是毫秒时间戳被当成秒解析，或 claims 里放的是自定义字段名（如 createTime），工具只自动换算标准 iat/exp/nbf 字段。

Q: JWT 解码需要密钥吗？

不需要。JWT 的 header 和 payload 只是 Base64Url 编码，任何人都能解出原文，这也是「不要在 payload 放敏感信息」的根本原因。密钥只在验证签名时用——服务端通过重算签名确认 token 没被篡改。

Q: JWT 是加密的吗？

默认不是。常见的 JWS（签名型 JWT）内容完全可读，只保证不可篡改；要加密得用 JWE（加密型 JWT），用接收方公钥加密整个 token。绝大多数业务系统用 JWS 即可，敏感信息应放服务端 session 而非 token 里。

Q: 签名算法 HS256 和 RS256 怎么选？

HS256 是对称加密：签发和验证用同一把密钥，适合单体应用；RS256 是非对称：私钥签发、公钥验证，适合微服务和开放授权——验证方拿不到私钥，无法伪造 token。跨组织场景必须 RS256 或 ES256。

Q: alg 设为 none 是什么漏洞？

早期部分 JWT 库接受 header 声明 alg 为 none 的 token（即不验签），攻击者把算法改成 none 并删掉签名段就能伪造任意身份。修复：服务端白名单固定算法，禁止 none；另一个经典攻击是把 RS256 改成 HS256，用公钥当 HMAC 密钥签名——算法白名单同样能防。

Q: JWT 过期了怎么无感刷新？

双 token 方案：短期 access token（15 分钟-2 小时）+ 长期 refresh token（7-30 天，httpOnly cookie 存储）。access 过期后用 refresh 换新对，服务端同步轮换 refresh token；检测到旧 refresh 被复用就整族吊销，这是防 token 被盗用的标准做法。

Q: JWT 怎么主动吊销？

JWT 设计成无状态，天然不支持吊销。常用方案：jti 黑名单（把吊销的 token 编号存 Redis，有效期到原 exp 自动清除）；改用户级密钥盐（全员踢下线）；缩短 access 有效期+refresh 可吊销组合。金融级系统常用最后一招。

Q: JWT 存在 localStorage 还是 cookie？

各有取舍：localStorage 简单但可被 XSS 脚本读取；httpOnly cookie 防 XSS 但要处理 CSRF（需配合 SameSite=Strict/Lax 或 CSRF token）。主流建议：refresh token 必须 httpOnly cookie，access token 放内存（页面变量），不落盘。

什么是JWT 解码器？

JWT（JSON Web Token，RFC 7519）是现代 Web 最主流的无状态身份凭证，由三段 Base64URL 编码拼接而成：Header.Payload.Signature。Header 描述签名算法（如 HS256、RS256）；Payload 携带声明（claims）——iss 签发者、sub 主题、exp 过期时间、iat 签发时间等；Signature 是前两段加上密钥的签名，用于防篡改。

解码（Decode）与验证（Verify）是两回事：Base64URL 解码人人可做，所以 JWT 里绝不能放密码等敏感信息；验证签名才需要密钥。本工具只做解码与格式检查，签名校验必须在服务端用密钥完成。调试接口时，解码 JWT 是排查「401 未授权」的第一步——八成是 token 过期或字段填错。

解码 JWT 时重点看三段内容：Header 里的 alg 决定签名算法，必须警惕 alg=none 的降级攻击——攻击者可把 alg 改成 none 并去掉签名伪造任意 token，服务端若信任 Header 就会放行。Payload 里常见声明 exp（过期时间）、iat（签发时间）、sub（主体）、iss（签发者）、aud（受众），调试时核对 exp 是否已过期、iss/aud 是否符合预期，多数「token 无效」都是这三处不匹配造成。

安全铁律：JWT 的 Payload 只是 Base64URL 编码而非加密，任何持有 token 的人都能读出来，所以严禁放密码、密钥、身份证号等敏感字段。签名只保证「未被篡改」，不保证「内容保密」。需要保密就用 JWE（加密的 JWT），或改用服务器端 session 存储敏感数据。本工具的解码结果可用于排查接口 401/403，但真正的校验永远要在服务端用秘钥完成。

exp − 当前时间 = 剩余有效期；exp < 当前时间 → Token 已过期

JWT 三段结构：header.payload.signature，每段都是 Base64Url 编码，解码 payload 即可读出全部声明（claim）。示例：payload 解码后得到 {sub: 用户123, iat: 1729000000, exp: 1729003600}，有效期 = exp − iat = 3600 秒（1 小时）。关键认知：解码 ≠ 验证——任何人都能解码看内容，签名只是防篡改，不是加密；敏感数据（密码、身份证）绝不能放进 payload。

常见 JWT 声明（claim）速查
声明	含义	典型用法
iss（签发者）	谁签发的 token	校验来源，防跨系统混用
sub（主体）	token 属于谁	通常是用户 ID
exp（过期时间）	Unix 秒，过期即失效	服务端必校验，客户端做刷新预判
iat（签发时间）	Unix 秒	配合 exp 算有效期
nbf（生效时间）	此前 token 无效	延迟生效场景
aud（受众）	token 给谁用	多服务隔离，防串用
jti（唯一编号）	token 身份证	黑名单吊销、防重放

如何使用JWT 解码器

1
把完整的 JWT（三段以点分隔的字符串）粘贴到输入框。
2
点击「解码」，查看 Header 与 Payload 的格式化 JSON。
3
查看 iat（签发时间）、exp（过期时间）的本地时间换算与剩余有效期。

计算示例

例 1示例 1：常规登录 Token

Header {"alg":"HS256","typ":"JWT"}；Payload 含 sub: "user123"、iat: 1735689600（2025-01-01 08:00）、exp: 1735693200（2025-01-01 09:00）——有效期 1 小时的短时效访问令牌。

例 2示例 2：过期判断

exp 为 1700000000 的 Token，当前时间已晚于该值 → 工具显示「已过期 X 天」，这就是接口返回 401 的原因，需要用 refresh token 换新。

注意事项

JWT 只是编码不是加密：Payload 任何人都能解码，千万不要在里面放密码、身份证号等敏感信息。
本工具在浏览器本地解码，Token 不会发送到任何服务器，但生产环境的 Token 仍建议只在受信任的设备上调试。
Base64URL 与标准 Base64 的差别是字符集（- 替换 +、_ 替换 /）且通常省略末尾 = 填充，解码时需注意。
exp/iat 都是 Unix 秒级时间戳（不是毫秒），相差 1000 倍会解析出离谱的日期。

常见问题