图片转 Base64 有什么用？Data URI 用法与体积代价

Base64 是什么？体积为什么会变大？

Base64 把每 3 个字节拆成 4 组 6 位，再用 64 个字符逐组表示，所以输出长度固定是输入的 4/3。这 64 个字符是 A～Z、a～z、0～9 加上 + 和 /，全都是可打印字符，放进任何文本里都不会被当成控制符。

长度可以直接算：

Base64 字符数 = 4 × ⌈原始字节数 ÷ 3⌉

字节数不是 3 的倍数时，末尾用一个或两个 = 补齐。用几张图实测，比例几乎钉死在 1.3333：

小图标的比例略高，是因为 data:image/png;base64, 这 22 个字符的前缀在小文件里占比更明显。这里有个常见误解：Base64不是压缩，也不是加密，它只是换了一种写法，任何人都能原样解回图片。

Data URI 在 HTML、CSS、JSON 里怎么写？

格式固定为 data:[类型];base64,[内容]，类型要和图片真实格式一致，PNG 写 image/png，JPG 写 image/jpeg。下面是四种常见写法。

HTML 图片标签

<img src="data:image/png;base64,iVBORw0KGgo..." alt="搜索" width="16" height="16">

和普通图片一样补上 alt 和宽高，否则读屏软件读不出含义，页面也会在加载时跳动。

CSS 背景图

.icon-search {
  background-image: url("data:image/png;base64,iVBORw0KGgo...");
}

JSON 接口或配置文件

{
  "avatar": "iVBORw0KGgo...",
  "avatarType": "image/png"
}

接口里通常只放纯 Base64，类型单独用一个字段说明，前端拼成 Data URI 再显示。

SVG 图标：不用转 Base64

SVG 本身就是文本，直接做 URL 编码写进去更短，而且源码可读、可改颜色：

background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' ...%3E");

实测一个 213 字节的放大镜图标，Base64 版 Data URI 是 310 个字符，URL 编码版是 250 个字符，短了约 19%。写法要点是把双引号换成单引号，并转义 < > # % 这几个字符。

PNG、JPG、WebP 这些二进制图片没法这么写，只能走 Base64。用图片转 Base64可以一键生成上面四种形式，不用手动拼前缀。

开了 gzip，还要在乎那 33% 吗？

传输层面基本不用在乎，真正的代价在别处。Base64 只用了每个字符 8 位里的 6 位，gzip 恰好能把这部分冗余压回去。

单位为字节。换成 Brotli 压缩，结果与原图基本持平。所以“内嵌会让下载量多三分之一”这个说法，在开了压缩的服务器上并不成立。内嵌大图真正亏在下面几件事：

• 没法单独缓存。图片写进 CSS 后，改一个颜色、调一个间距，整份 CSS 连同里面的图片都要重新下载。单独的图片文件则能长期缓存。
• 拖慢首屏。CSS 是阻塞渲染的资源，浏览器要等它下载并解析完才开始绘制页面。往 CSS 里塞一张 100KB 的图，等于让整个页面多等这 100KB。
• 不能懒加载。普通图片可以等滚动到视口附近再加载，内嵌的图片随 HTML 或 CSS 一起到达，看不看得到都要付出成本。
• 重复引用会重复计费。同一个 Data URI 在页面里写三次，就是三份数据；普通图片链接只下载一次。
• 解压后仍是 4/3。gzip 只省传输，浏览器内存里的文本还是完整大小，还要多一步解码。

什么图该内嵌，什么图不该？

一句话：小、少、稳的图内嵌，大、多、常变的图走链接。前端构建工具 Vite 默认把 4KB 以下的资源自动转成 Base64 内联，这个值可以作为日常判断的参考线。

HTML 邮件里为什么要谨慎

邮件不是浏览器，各家客户端对 Data URI 图片的处理差别很大：有的正常显示，有的出于安全考虑直接屏蔽，显示成一个空白框。发营销邮件或通知邮件时，稳妥的做法有两种：一是把图片放在服务器上用普通链接引用；二是把图片作为附件嵌入，正文里用cid: 引用它。不管选哪种，群发前都要在常用的几个客户端里各发一封测试邮件看效果。

内嵌前先把图压小

Base64 会原样放大原图的体积，所以先压缩再编码，收益会被 4/3 一起放大。一张 12KB 的图标压到 4KB 再转，内嵌后是约 5.4KB 而不是 16KB。小图标先用压缩图片处理一遍，带透明的保持 PNG 或 WebP 格式。

解码 Base64 时要注意什么？

以文件头判断格式，不要相信前缀里写的类型。data:image/png;base64, 只是一段谁都能写的文本，内容可能根本不是 PNG，甚至不是图片。可靠的判断方式是看解出来的前几个字节：PNG 以固定的 8 字节签名开头，JPG 以 FF D8 开头。小鹿 Image 的解码就是按文件头判断，前缀和内容对不上时以内容为准，不是图片则直接报错。

常见的解码失败原因

• 复制不完整：日志、聊天记录常把长文本截断，解出的图片下半截发灰或损坏。
• 混入了别的字符：换行、空格一般会被忽略，但中文引号、省略号混进去就会解错。
• URL 安全变体：有的系统把 + 和 / 换成了 - 和 _，需要解码器兼容这种写法。
• 内容被转义过：JSON 里的斜杠有时被写成 \/，先还原再解码。

安全上的两个边界

一是主流浏览器会拦截网页用链接或脚本跳转到 data: 地址，这是为了防止伪装成正常网址的钓鱼页；在 img 标签和 CSS 里当图片用则不受影响。二是来路不明的 SVG 类 Data URI 不要当网页直接打开，SVG 里可以带脚本，作为 img 显示时脚本不会执行，单独打开则不一定。

需要把 Base64 还原成文件时，直接粘进图片转 Base64的解码一侧；想了解各图片格式本身的差别，可以看图片格式怎么选。