iLoveDevTool先分流：你手里的是什么
「Base64」搜索框背后是四种不同的活，先看手里东西的形态：
| 形态 | 你要做的事 | 怎么做 |
|---|---|---|
一串字母数字，结尾 0-2 个 = |
解出文本内容 | 贴进 Base64 编码解码器 解码，UTF-8 内容直接还原中文 |
data:image/png;base64,... 开头 |
看这是什么图 / 还原成图片 | 贴进工具——识别 data URI 与图片签名（PNG/JPEG/GIF/WebP/BMP），给出预览 |
| 本地文件 | 转成 Base64 内嵌（CSS 小图标、JSON 传参） | 切文件模式上传（上限 5MB），得到 dataURL 或纯编码 |
| 编码结果要放进 URL、文件名 | 避免特殊字符出事 | 选 URL-safe 变体（+→-、/→_、去掉 =） |
四种情况共用一个事实：Base64 是可逆编码，不需要密钥，贴进工具就能双向转换。下面讲最容易翻车的三个问题。
乱码的三大来源
解码出乱码，先别怀疑内容坏了，按概率排查：
一、字符集误读（最常见）：内容是 UTF-8 编码的中文，解码工具却按 Latin-1 逐字节显示——每个汉字的三个 UTF-8 字节变成三个西欧字符，满屏 ä½ å¥½ 就是这个 pattern。解法：用支持 UTF-8 的工具（本站解码走 UTF-8 管线，中文直接还原）。
二、本来就是二进制：图片、压缩包、protobuf 序列化数据——它们不是文本，强行按文本渲染当然是乱码。判断方法看签名：解出来开头是 \x89PNG 是 PNG 图片、FF D8 FF 是 JPEG、PK 开头多半是 ZIP——这时候正确动作是还原成文件而不是当文本读。带图片识别的解码器会直接给出预览。
三、多层编码没剥干净：上游先做了百分号编码（%E4%BD%A0）再做 Base64，或 JSON 里的字符串转义没去掉——逐层剥：先去转义、再解外层、再解内层。判断线索是解出来的「乱码」本身看起来像另一种编码的形态。
URL-safe：三个字符引发的事故
标准 Base64 的字母表（A-Z a-z 0-9 + /）在纯文本世界里没问题，但 +、/、= 三个字符各有雷区：
+在 URL 查询参数里会被服务端解析成空格——签名校验就是这么失败的；/在文件名里不合法，在 URL 路径里会被当成分隔符；=是 padding，放在查询参数里部分网关会截断或重复解码。
URL-safe 变体把 +→-、/→_、去掉 =，产出可安全放进 URL、文件名、正则上下文。JWT 的载荷部分用的就是它。判断标准：这段编码接下来要去哪里？ 去 URL/文件名选 URL-safe；只在程序内部传递用标准形态，别为「看起来更安全」乱换——两种形态只是字母表不同，解码端必须配套。
文件与 dataURL
把文件转成 Base64 的主要产出是 dataURL——data:image/png;base64, 前缀加编码串，浏览器能直接把它当图片地址用。
划算的用法：几 KB 的 CSS 内嵌小图标（省一次请求）、邮件内嵌图片、配置文件里携带小型二进制资源、给接口传「小文件+元数据」的复合结构。
不划算的用法：大图内嵌——体积膨胀三分之一（算法固有：4 字符表 3 字节），100KB 图片编码后约 133KB，页面里塞几张就把传输与解析开销吃回来了。经验值：几 KB 到几十 KB 的静态资源适合内嵌，更大走独立文件与 CDN。
真话段：Base64 不是加密。无密钥、算法公开、一步还原——把密码或 token 转成 Base64 当「混淆」，在任何扫描器面前等于明文。它的正当用途是让二进制数据安全通过文本通道（HTTP 头、JSON、URL、邮件），与保密无关。要保密用加密，要管密码用密码管理器。
常见问题
Base64 解码出来是乱码怎么回事？
三个来源按概率排：一是字符集误读——内容是 UTF-8 编码的中文，但查看工具按 Latin-1 逐字节显示，解出来必然是乱码，换支持 UTF-8 的解码工具即好；二是解的本来就是二进制（图片、压缩包、序列化数据），强行按文本渲染当然是乱码——看开头几个字节的签名判断真实类型；三是编码源头就错了，比如上游先做了百分号编码再 Base64，需要逐层剥。先判断手里的是什么，再选解法。
Base64 是加密吗？用它藏密码安全吗？
不是，完全不安全。Base64 是编码不是加密：算法公开、无密钥、任何人都能一步还原。把密码转成 Base64 的唯一效果是「肉眼不可读」，对攻击者等于没设防——它出现在无数扫描器的默认字典里。真正的保密要靠加密（AES 等带密钥算法）或更好的方案——密码管理器与凭证存储。Base64 的正当用途是「让二进制安全地过文本通道」，与保密无关。
什么时候必须用 URL-safe Base64？
标准 Base64 的字母表里有 + / = 三个字符，它们在 URL 里有歧义（+ 会被解析成空格）、在文件名里不合法、在正则里要转义。URL-safe 变体把 + 换成 -、/ 换成 _、去掉 padding 的 =，产出可以安全放进 URL 路径、查询参数、文件名。判断标准：这段 Base64 接下来要去哪里？去 URL/文件名就用 URL-safe；只在程序内部传递就用标准形态。
为什么图片转成 Base64 后体积变大了？
Base64 用 4 个字符表示 3 个字节，任何内容编码后体积固定膨胀约 33%——100KB 的图片编码后约 133KB。这是算法代价不是 bug。用它做 CSS 内嵌小图标、邮件内嵌资源是划算的（省一次请求）；把大图转 Base64 塞进 JSON 或 CSS，页面体积与解析开销都会明显上涨。经验值：几 KB 到几十 KB 的静态小图适合内嵌，再大就该走独立文件与 CDN。