先做两个已知答案的往返实验

在Base64 工具输入 你好，保持“标准 Base64”，点击“编码”，结果应为 5L2g5aW9；将结果放回输入框再点“解码”，应恢复 你好。这表示浏览器先把文字变成 UTF-8 字节，再用 Base64 表示字节。直接对中文字符串调用 btoa 可能报错，因为该接口接受的是单字节字符。

再输入单个字母 f：标准 Base64 输出 Zg==；切换到“Base64URL”后输出 Zg。这组短样例容易看清填充符 = 的差异。Base64URL 还将标准字母表中的 +、/ 替换成 -、_。切换模式时，请以来源协议要求为准。

三种常见失败，处理方式不同

  1. 编码字符串损坏：复制时丢了字符，或者查询参数中的 + 被当作空格。先对照原始响应；把普通 Base64 放进 URL 参数时应使用 URL 参数编码，不能靠手动替换几个字符。
  2. 解码出的字节不是 UTF-8：图片、压缩文件和其他二进制内容可能是合法 Base64，但不能当文字显示。本站工具会明确报“不是 UTF-8 文本”，不会把替代字符当作成功结果。
  3. 字符集不一致：上游把文本按 GBK 等编码转成字节，下游却按 UTF-8 读取，可能乱码或解码失败。需要在数据产生处确认字符集，再用匹配的解码器；反复尝试在线工具不能确定原始字符集。

JWT 可以解码，不代表可以信任

JWT 的头和载荷通常以 Base64URL 表示。你可以把一个片段放入本页工具查看其中的 UTF-8 JSON，但这只是读取声明；它不会验证签名、令牌来源、有效期、受众或业务权限。比如任意人都能构造一段写着 {"role":"admin"} 的编码文本。应用只应在可信服务端按所用 JWT/JWS 规范与密钥验证后使用这些声明。

Base64 不是加密。不要把编码后的密码、访问令牌或个人资料当作安全分享形式；向工单提交样例时用假的值替换真实数据。

最短排查记录

原始字段来自哪里：HTTP 响应体 / URL 参数 / JWT 片段
期望变体：标准 Base64 / Base64URL
预期内容：UTF-8 文本 / 二进制文件
实际报错：格式无效 / 非 UTF-8 / 解码后文本不符
已脱敏的最小样例：Zg== → f

规范依据：RFC 4648 标准 Base64、RFC 4648 Base64URL、RFC 7519 JWT 验证步骤。