JWT 解析
把 JWT 的三段拆开，看清 header、payload 和过期时间——但请记住：这只是解码，不是验证。
这个工具只做解码，不校验签名
它不会验证 token 是否由可信方签发，也不会判断 token 是否有效。任何人拿到 token 都能改掉 payload 里的内容、用相同格式重新编码，做出一份看起来完整、格式也正确的 token。要判断真伪，服务端必须用自己的密钥或公钥重新验签。所以：解码结果只能用来排查问题，不能作为鉴权依据。
输入
输出
它拆出来的是什么
JWT 是两段点号分隔的三部分字符串：header、payload、signature。前两段是 base64url 编码的，所以整串里看不到加号、斜杠和等号。解码后 header 告诉你算法和类型（alg、typ），payload 是一组声明（claims），常见的有 iss 签发者、sub 主体、aud 接收方、exp 过期时间、iat 签发时间、nbf 生效时间，第三段才是签名。
base64url 和普通 base64 只差三个字符：+ 换成 -、/ 换成 _，并且末尾的 = 补位经常被省略。所以解码时要先还原这两个字符、补回等号，再按 UTF-8 解析，否则中文和 emoji 会变成乱码，最后还可能出现「字符串长度不对」的解码失败。
最常见的误用：把解码当验证
header 和 payload 都是明文可读的，没有加密。有人看到页面上显示 exp 还没到，就以为 token 是有效的——这正好搞反了。payload 里的任何字段都能被随意改写，改完再编码一次，格式依然完全合法。服务端如果只做解码、不验签，攻击者就能伪造出任意身份。JWT 的安全性完全来自签名校验，客户端解码只是调试手段。
另外一点：token 一旦泄露就是凭据本身，不要粘贴生产环境的真实 token 到任何第三方页面（包括本页）。本站的处理全在浏览器里、不上传数据，但习惯上仍然应该用脱敏或测试环境的 token 做排查。
常见问题
JWT 的 payload 是加密的吗？
不是。payload 只是 base64url 编码，任何人都能解开看。不要在 payload 里放密码、身份证号、完整手机号这类敏感信息，只放标识符和过期时间。
解出来显示未过期，就说明 token 有效吗？
不能这么理解。本工具不校验签名，任何人都能把 payload 改掉再用相同格式重新编码。有效期显示只是按你本机时间做的比较，服务端必须验签才能判断 token 真伪。
过期时间 exp 的判断和服务器不一致？
exp 是否过期是按你本机的系统时间比较的，本机时钟有偏差就会和服务器判断不同。另外 exp 表示的是“不早于该时刻失效”，服务端通常还允许几十秒的时钟偏移，最终以服务端为准。
为什么 signature 段显示成乱码？
签名是二进制字节（HMAC 或 RSA/ECDSA 的结果），base64url 解码后并不是文本，显示成乱码是正常的。只有用对应密钥或公钥跑验签程序，才能判断签名对不对，解码本身说明不了任何问题。
提示段数不对怎么办？
JWT 必须正好由两个点号分成三段。段数不对通常是复制时被截断，或者把
Bearer 前缀、引号、换行、逗号一起粘了进来。先清理掉这些多余字符再试。