JWT 在线解析与签名校验
拆解 JWT 的 Header 与 Payload，查看签发与过期时间，并在本地校验 HS256 签名，密钥不外传。
调试登录接口时，拿到的 Token 是一长串看不出内容的字符：想知道它属于哪个用户、什么时候过期、签名对不对，就得把它拆开看。手工做 Base64URL 解码既麻烦又容易把 - 和 _ 处理错，用在线工具又担心把密钥交出去。
本工具只做本地解析：三段内容由浏览器内置的解码能力与 Web Crypto 处理，HS256 校验用的密钥始终留在当前页面内存中，不会随请求发往任何服务器。需要提醒的是，解析成功、验签通过只说明 Token 结构合法且签名匹配，不代表服务端一定会接受它。
JWT 的三段结构与编码
JWT 由 header.payload.signature 三段组成，中间用点号分隔。前两段是 JSON 经过 Base64URL 编码的结果：Base64 里的 + 换成 -、/ 换成 _，末尾的 = 去掉，这样才能安全地放进 URL 和 HTTP 头。签名段是对「header.payload」这段原文、用指定算法计算出来的（HS256 用共享密钥，RS256 用私钥），服务端拿同样的输入重算并比对，就能判断内容有没有被改动。
Payload 是明文可见的
很多人以为 Token 看不懂就等于加密了，其实 Payload 只是 Base64URL 编码，拿到 Token 的人都能解开看到里面全部字段，所以密码、手机号、身份证号、内部接口地址都不应写进 Payload。exp、nbf、iat 分别是过期、生效、签发时间，单位是 Unix 秒级时间戳。只校验 exp 并不够，服务端还应校验 iss、aud 与签名算法的白名单，避免被篡改成 none 算法绕过校验。
签名校验为什么要在本地做
校验 HS256 需要同时输入共享密钥和 Token，如果在线工具把这两样发到服务端，密钥就已经泄露了，等于把签发权限交给第三方。本工具用浏览器内置 Web Crypto 的 HMAC-SHA256 在页面内完成计算，密钥只存在于当前内存，刷新即消失。还要记住一点：验签通过只证明内容与签名匹配，不能证明 Token 由可信方签发，也不能替代服务端对有效期和权限的判断。
常见问题
- JWT 的 payload 是加密的吗？
- 不是。Payload 只是 Base64URL 编码的 JSON，没有任何密钥参与，任何人复制到解码工具里都能读到全部字段。需要传递敏感信息时应在应用层单独加密，或者干脆不放进 Token。
- 签名校验通过就能说明 Token 有效吗？
- 不能。验签只证明内容没被篡改、签名方持有对应密钥。Token 是否可用还要看 exp 是否过期、nbf 是否已生效、iss/aud 是否匹配，以及服务端有没有主动拉黑；JWT 本身无状态，签发后无法单方面作废。
- 为什么我的 JWT 验签总是失败？
- 常见原因有三类：密钥不对或编码方式不一致（有的是原始字符串，有的是 Base64 解码后的字节）；算法选错，RS256 的 Token 用 HS256 校验必然失败；Token 复制时多了换行空格，或者 base64url 的 - _ 被替换成了 + /。
- exp 为什么是一串数字而不是日期？
- JWT 的 exp、nbf、iat 都用 Unix 时间戳，单位是秒，即从 1970-01-01 UTC 起经过的秒数。不少语言取到的是毫秒，需要除以 1000；时区不参与计算，显示成本地时间只是换算的结果。