关于 Base64 编码/解码
Base64 最常见的用途不是「加密」，而是把二进制数据塞进只允许文本的通道：把图片内联进 CSS 的 data URI、把证书或密钥嵌进配置文件、把一段二进制日志贴进聊天窗口、给 HTTP Basic 认证拼 Authorization 头。凡是遇到「这里只能放字母数字和符号」的场合，通常就是它。 编码原理是把每 3 个字节（24 位）重新切成 4 个 6 位单元，再按固定字母表映射成 64 个可打印字符；不足 3 字节时用 = 补齐。因为多出来的只有填充位，Base64 的体积约为原文的 133%——这一点常被忽略，把大图片直接内联成 data URI 会让页面体积明显膨胀。 使用要点：标准 Base64 的字母表包含 + 与 /，放进 URL 必须替换成 - 与 _（即 URL-safe 变体），否则路径或查询参数会被解析错；中文等非 ASCII 内容要先按 UTF-8 编码再 Base64，如果另一端按 GBK 解码就会得到乱码。解码时若原文是文本，注意区分「解出来是 UTF-8 文本」还是「解出来就是二进制文件」，后者应直接以文件形式保存而不是当字符串展示。 边界与限制：Base64 不是加密，任何人都能解出原文，把口令、令牌、身份证号「Base64 一下」并不能保护它们；标准没有规定换行，但很多实现默认每 76 个字符插入换行，跨系统时要么统一加换行要么统一去掉；末尾的 = 在部分实现里是可选校验，缺了可能仍能解出，因此不要用它判断数据完整性。此外，带前缀的 data URI（形如 data:image/png;base64,）需要先剥掉前缀再解码。 数据与隐私：需要编码的内容往往是密钥、证书私钥、带签名的令牌或含个人信息的导出文件，这些数据泄露的后果远大于一次格式转换的价值。本工具在浏览器内完成编码与解码，不发起上传；对于私钥这类材料，稳妥做法是断开网络后再操作，并确认开发者工具的网络面板全程没有请求。
几个容易忽略的实现细节。浏览器提供的 btoa 只能处理拉丁字符，直接传入中文会抛 InvalidCharacterError，必须先用 UTF-8 编码成字节序列再逐字节转换，自行拼接字符串或依赖 encodeURIComponent 的写法都应明确注释，否则下一个人很容易改坏。体积上，Base64 比原文大约三分之一，把它用作「压缩后传输」的手段是反效果；真正需要压缩时应先走 gzip 或 Brotli，再对压缩结果做 Base64。批量场景下，超大文件（几十兆以上）在浏览器里需要分块读取，一次性读取会占用大量内存并可能触发页面崩溃。最后，某些老旧系统期望字母表使用 + 与 /，而 URL 与文件名场景要求 - 与 _，跨系统对接前先约定变体，比事后排查「参数被解析成两个」要省事得多。
顺带说明它与相邻编码的分工：URL 编码解决的是「把任意字符放进 URL」，十六进制解决的是「把字节写成可读形式」，Base64 解决的是「把字节塞进文本通道」。三者的适用场合不同，混用会让体积与可读性都变差。 需要长期保存编码结果时，建议记录所用变体（标准或 URL-safe）与是否换行，这两项信息缺失往往比编码本身更容易导致对接失败。以免对方按默认假设处理。
实现原理
编码把每 3 个字节（24 位）重新切成 4 个 6 位单元，再按固定字母表映射成可打印字符；不足 3 字节时用等号补齐。因此输出长度恒为「向上取整到 3 的倍数后乘以 4/3」，这解释了为什么结果总比原文长约三分之一。解码是它的逆运算，不需要密钥，也不做任何校验。
oltoolb2x0b29s使用方法
- 打开 Base64 转换工具
- 选择编码或解码模式
- 在输入区域粘贴文本或上传文件
- 点击「转换」按钮，结果将实时显示
- 复制转换结果
使用场景
- Data URI 嵌入图片 — 把小图片转 Base64 直接嵌入 CSS 或 HTML，减少 HTTP 请求。
- API 传输二进制 — JSON 不支持二进制字段，文件、加密结果常以 Base64 字符串传输。
- 调试 JWT — JWT 三段都是 Base64URL，本工具可单独解码看 header / payload 内容。
- 邮件附件 — SMTP 协议要求附件用 Base64 编码后才能在文本邮件里传输。
- 配置文件密钥 — YAML / JSON 配置文件里存证书、密钥时常用 Base64 表示。
常见问题
Base64 是加密吗？
不是。Base64 只是编码——任何人都能轻松解码。如需保密请用 AES（本站「AES 加密」工具）。
为什么编码后体积变大了？
Base64 用 4 个字符表示 3 字节，体积会膨胀约 33%。这是为了把任意二进制塞进文本通道的代价。
Base64 和 Base64URL 有什么区别？
Base64URL 把 + 和 / 替换成 - 和 _，并去掉填充的 =，使其在 URL 和文件名中安全。JWT 用的就是 Base64URL。
为什么解码失败？
常见原因：(1) 字符串包含非 Base64 字符（如换行、空格）；(2) 末尾 = 填充缺失；(3) URL 安全变体没替换回 + /。
能编码图片吗？
能。需要先把图片读为二进制（Blob/ArrayBuffer），再转 Base64。本站还有「文件转 Base64」专用工具，直接拖拽图片即可。
为什么解码出来是乱码？
常见原因有三种：一是源字符串本身不是用 UTF-8 编码的文本，而是二进制（如图片、压缩包、加密结果），BASE64 解码后自然显示成乱码，需先确认内容的真实类型；二是输入其实不是标准 Base64，可能混入换行空格，或被 URL 编码工具把 + 转成了空格、把 / 转义了，解码前先清除这些非 Base64 字符；三是解码后的文本字符集不是目标使用的编码。排错顺序：先确认是否真的要在文本通道里传二进制，再清理输入的非 Base64 字符，最后用 Unicode 正确解码。
Base64 里的换行会影响解码吗？
会。一些编码器或邮件协议会按每 76 个字符插入回车换行（参考 RFC 4648 的行宽建议），严格解码器遇到这些换行、空格会直接报错或导致结果错乱。如果你粘贴的是带换行的 Base64，先移除所有 ASCII 空白（换行 \n、回车 \r、空格）再解码即可。多数现代编程语言在严格模式下也会拒绝空白，需用替换或正则先行清理。规范的做法是先用正则 [^A-Za-z0-9+/=] 过滤掉非 Base64 字符，再交给解码函数。
Base64 编码后比原文长了三分之一？
Base64 把 3 字节编码成 4 个字符，体积固定变为约 4/3，这是编码机制的固有开销，不是实现问题。所以它适合「让二进制数据通过文本通道」，不适合压缩——需要缩小体积应该先压缩再编码。