Base64URL 解码指南：看懂 JWT，但别相信它

解码只是把字母表换回来。看到 payload 里的 role: admin 不代表这个 token 可信——那要靠签名验证，而验证必须在服务端做。

最常见的用途：看 JWT 里写了什么

调试登录流程时，把 token 中间那段粘进来，就能看到 sub、exp、scope 这些字段。因为 payload 是 Base64URL 的 JSON，解码后直接可读，不需要密钥，也不需要联网。

另一个场景是链接里的参数：分享链接、回调地址、埋点参数经常把 JSON 压成一段 Base64URL。解开后才知道对方到底传了什么，比对着编码猜快得多，也更容易发现多传或漏传的字段。

工具会把 - 和 _ 换回 + 和 /，再按长度补上 =，然后解码。失败通常有三个原因：字符串被截断（复制时少了几位）、混入了 URL 里的 %20 或中文、以及内容根本不是 Base64URL 而是一段普通文本。

还有一种是「解出来是乱码」：这说明字节不是 UTF-8 文本，可能是加密后的密文、压缩数据或图片。Base64 只保证字节可逆，不保证解出来能读，遇到乱码就该换工具，而不是反复重试。

JWT 的 header 里写着 alg，但你不能因为这个字段就相信它。经典的 alg: none 攻击，就是利用「客户端说用什么算法就用什么」的信任错位。验证必须在服务端按预期算法和密钥进行。

Base64URL 不是加密，解码也不需要密钥，任何人都能做同样的事。别把解密、验签、解码混为一谈：解码回答「里面写了什么」，验签回答「是不是签发者写的、有没有被改过」。

解出来是乱码怎么办？

说明原始字节不是 UTF-8 文本。它可能是密文、压缩包或图片，Base64 只负责把字节搬来搬去。先确认来源，再选对应的解密或解压工具，不要反复解码。

需要自己补 = 吗？

不需要，工具会按长度补上等号。手工补的时候注意总长度必须是 4 的倍数，补错数量反而会解出错误内容，而且不会报错，最好让工具自动补。

能验证 JWT 签名吗？

不能。这个工具只做解码，不持有密钥，也不校验证书。签名验证必须在服务端用可信密钥完成，客户端解出来的内容只能当参考，不能作为授权依据。