Base64 解码失败或重新编码不一致：格式、UTF-8 与 BOM 怎么查

更新于 2026-10-12 · 网查工具箱

区分格式错误、非 UTF-8 字节与隐藏字符，用 hello、换行和 BOM 样本复核当前结果。

先分清是格式错误，还是字节不能当文本

Base64 把字节表示为文字，并不保证这些字节是 UTF-8 文本，也不是加密。在Base64 文本工具中选择解码，先用 aGVsbG8= 复核，应得到 hello；不要使用真实密码、令牌或客户资料做测试。

标准 Base64 使用字母、数字、+、/，末尾可能有 = 填充。浏览器原生 atob 会接受部分省略填充及 ASCII 空白的形式；能在浏览器解码，不代表目标接口也接受相同格式。本工具沿用原生解析器，不自动修补损坏的内容。

报错一：标准 Base64 内容无效

输入 * 或 aGVsbG8=== 应报格式错误，而不是成功文本。若复制的是 data:text/plain;base64,aGVsbG8=，前面的 data: 内容是 Data URL 的描述，不属于待解码的 Base64 正文；仅在明确知道来源格式时取逗号后的内容。本工具不会替你自动删除前缀。

Base64URL 把标准 Base64 的 +、/ 换成 -、_，不是同一种字符表。例如标准 Base64 的 8J+YgA== 可解出一个表情字符，但 8J-YgA== 在本站的标准模式会报错。若处理 JWT 等格式，应按其协议使用相应解码器；读到载荷也不代表签名或权限有效。

报错二：字节不是有效 UTF-8

/w== 是合法 Base64，得到的单个字节是十六进制 FF，但它不能单独构成有效 UTF-8。本工具应提示“已还原为字节，但不是有效的 UTF-8 文本”，不会输出替换字符来冒充正确解码。图片、压缩包或采用其他字符编码的内容，应使用与来源对应的二进制或字符编码处理方式；不要把报错认定为内容已经损坏，也不要猜测编码后覆盖原文。

看起来都是 hello，字节可能不同

以下样本可直接放入解码模式。换行样本最后有一个 LF，不是字面上的反斜杠加 n；BOM 样本开头是 U+FEFF，肉眼可能看不到：

aGVsbG8=       hello，没有结尾换行
aGVsbG8K       hello 后有一个 LF 换行
IGhlbGxvIA==   hello 前后各一个空格
77u/aGVsbG8=   U+FEFF 后跟 hello

BOM 样本的 UTF-8 字节：EF BB BF 68 65 6C 6C 6F
BOM 样本的代码点：U+FEFF U+0068 U+0065 U+006C U+006C U+006F

2026-10-12 在本机 Windows Chrome 访问本站旧公网页面时，77u/aGVsbG8= 只解出五个可见字符，开头的 U+FEFF 被默认 TextDecoder 去掉。修复保留了这个字符：采用 fatal: true 和 ignoreBOM: true；后者在该 API 中表示把 BOM 包含在输出中，而不是删除。核对的对象是字符串和字节，不是截图里的文字外观。

文本框可能规范化 CRLF 换行；从文件复制文字也可能改变原文件的编码。因此该文本工具不承诺原文件字节往返不变。要核对下载文件或原始文件，请用文件 SHA-256 校验，不要仅比较复制后的显示文字。

验收时不要误用旧结果

在编码模式输入 hello，结果应为 aGVsbG8=，原文保持不变。
在 hello 后按一次回车，旧结果应立即消失；重新转换才应得到 aGVsbG8K。
切换编码/解码模式时，旧结果同样应消失。模式切换不自动替换输入，也不自动执行转换。
将 77u/aGVsbG8= 解码，保留包含 U+FEFF 的完整结果再重新编码，应得到相同 Base64；手动删去 U+FEFF 后则不再相同。

复核范围与隐私

本文使用公开的教学字符串，旧故障是在本机 Windows Chrome 对公网页面复现，不是其他浏览器或客户文件的检测结论。新版按上述样本及无效输入做本地浏览器验收；转换只在当前浏览器进行，不上传或保存输入和结果。本站的最近使用只保存工具 ID。浏览器扩展、设备剪贴板等环境仍需自行留意，Base64 不能用来保护秘密。

打开对应工具