把图片转成 Base64 后，你得到的是一个数据 URI（data URI），形如 data:image/png;base64,iVBORw0KGgo… 的字符串，可以直接粘进 HTML 的 src 或 CSS 的 url()。浏览器会就地解码并显示图片，不用单独下载，不用托管文件，也没有额外的请求。
那到底该不该这么做？规则很简短：当一张图很小（约 2 KB 以内）、几乎不变、而你想省掉一次 HTTP 请求时，就把它内联成 Base64，典型场景是小图标和 logo。其余情况，比如大图、跨页复用的图、想让浏览器缓存的图，都保留为普通图片文件。代价有两个：Base64 会让文件大约增大 33%，而且这段文本一旦嵌进 HTML 或 CSS，就再也无法被单独缓存了。
想知道某个具体文件的确切数字，图片转 Base64 转换器会在浏览器内完成编码，并显示精确的体积增幅，让你用真实数据而非经验法则来决策。下面会讲清这个 data URI 究竟是什么、体积开销背后的数学、何时内联划算的决策矩阵，以及哪些情况下普通文件更合适。
「图片转 Base64」实际产出的是什么：数据 URI
把图片转成 Base64 得到的不是文件，而是一段遵循 RFC 2397 定义的 data URI 格式的长字符串（完整规范见 MDN 的 data: URL 参考）。这个字符串有三个部分：
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
└──┬─┘ └───┬───┘ └─┬──┘ └─────────┬──────────┘
data: MIME type marker the encoded image bytesMIME 类型告诉浏览器它正在解码的是哪种图片。图片常见的有 image/png、image/jpeg、image/gif、image/webp、image/svg+xml，以及用于网站图标的 image/x-icon。;base64, 标记表示后面的载荷是 Base64 而非纯文本。逗号之后的全部内容就是图片本身，被重新表达为可打印的 ASCII。
最后这部分对隐私很重要。整个转换完全在你的浏览器中、通过 FileReader API 的 readAsDataURL 完成，没有任何内容上传到服务器。你可以把发布前的截图、内部图表或未公开的素材丢进工具，Network 标签页始终空空如也。原始字节如何变成那串 ASCII，理解 Base64 从头讲清了这种编码，Base64 完整指南 则把同样的 data URL 思路扩展到字体、PDF 和其他文件类型。
一个真实例子：68 字节的透明 PNG
这是最小的实用案例，一张 1×1 的透明 PNG，磁盘上 68 字节，下面是它完整的 data URI：
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==把它粘进浏览器地址栏，你就会看到（其实看不到，它是透明的）一张有效图片在零网络活动下渲染出来。注意结尾的 ==，那是 padding，后面会讲到。这和纯文本 Base64 长得一模一样，只是作用对象从文本字节换成了图片字节。如果你只需要编解码纯文本字符串，Base64 编码/解码工具就能搞定。
33% 的体积开销（以及它为何会叠加）
Base64 以固定分组工作：每 3 字节二进制变成 4 个 ASCII 字符。四除以三约等于 1.33，这就是 +33% 这个数字的来源。再加上一两字节的 padding 和 data:image/png;base64, 前缀，对极小文件来说开销会略高一些。比如一张 9 KB 的 PNG 会变成约 12 KB 的文本。
为什么恰好是 3 比 4？Base64 使用一个 64 字符的字母表：A–Z、a–z、0–9，再加上 + 和 /。64 个符号意味着每个字符携带 6 比特信息，而二进制字节每个是 8 比特。6 和 8 的最小公倍数是 24 比特，即 3 字节或 4 个 Base64 字符，于是编码器每次以 24 比特为单位推进处理整张图。当图片长度不是 3 的整数倍时，会用一两个 = 字符填补最后一组。这套数学是固定的，没有任何编码器设置能压低这 33%。
这 33% 是看得见的成本。看不见的成本在于它会叠加，而这正是大多数「直接内联就行」的建议略过的部分：
- 每当所在文件变更，图片就会被重新下载。 一个外部的
logo.png是独立资源。把它内联进styles.css后，对这份样式表的每次改动，哪怕只是调个颜色、加条规则，都会让图片的缓存一并失效。访客会重新下载他们本已拥有的图片。 - 它无法被独立缓存。 普通图片文件抓取一次，便可在每个页面、每次访问中复用。内联的 data URI 是文档的一部分，所以它会在每个嵌入它的页面、以及该文档每次缓存未命中时被重新发送。
- CSS 是阻塞渲染的。 浏览器在拿到 CSS 之前不会绘制。把一张大的 data URI 塞进样式表，你就放大了一个阻塞渲染的资源，从而延迟整页的首次绘制。
gzip 或 brotli 能抵消这 33% 吗？
部分能，但不彻底。Base64 文本重复度足够高，gzip 和 brotli 能很好地压缩它，在传输层挽回相当一部分膨胀。但有两点依然成立。第一，压缩后的 Base64 通常仍比压缩后的原始二进制略大，因为你给压缩器的是一个效率更低的起点。第二点也更关键：压缩对缓存和阻塞渲染毫无帮助。一个在传输层更小的 data URI，仍会随宿主文件一起被重新下载，仍无法被单独缓存。
换句话说，压缩并不等于消除内联的代价。如果你对 minify、gzip 和 brotli 之间的区别还有点模糊，代码压缩指南讲清了这几层是如何叠加的，以及为何把字节挤小永远修不好内联制造的缓存问题。
何时该用 Base64 图片（决策矩阵）
整个决策其实归结为下面这几个因素：
| 因素 | 倾向内联（Base64） | 倾向普通文件 |
|---|---|---|
| 大小 | 约 2 KB 以内（绿） | 超过约 10 KB（红）；2–10 KB 需酌情判断（黄） |
| 复用 | 单个页面、一两处 | 跨多个页面复用 |
| 变更频率 | 几乎从不变 | 经常编辑 |
| 场景 | HTML 邮件、自包含 widget 或 bookmarklet、JSON/API 载荷、值得省一次请求的关键首屏图标 | 内容图片、可缓存的共享资产 |
这些大小阈值不是随意定的，它们对应图片转 Base64 转换器内置的红绿灯徽章：2 KB 以内为绿、不超过 10 KB 为黄、超过则为红。工具会读取你的实际文件，告诉你它落在哪一档。
一条简单的经验法则
如果只记一句话：约 2 KB 以内且只用在一两处，内联通常划算；超过约 10 KB 或跨页复用，缓存的普通文件几乎总是更优。2–10 KB 这个中间地带，需要你针对具体情况，在省下的请求和丢失的缓存之间作权衡。
适用场景细说
下面几种情况，Base64 确实物有所值：
- HTML 邮件。 出于隐私考虑，许多邮件客户端默认屏蔽外部托管的图片，这会让任何依赖远程 logo 的版式破相。一个小的内联 data URI 不需要服务器抓取就能立即渲染。但要把它们限定在 logo 和图标上，绝不要把照片内联进邮件。
- 自包含的 widget 与 bookmarklet。 bookmarklet 或可嵌入的 widget 必须在零外部依赖下工作。内联它的图标能把一切都装进一个可拖放的单文件里。
- JSON 与 API 载荷。 把缩略图塞进 JSON 文档或配置文件里，有时是最干净的做法：一次往返、一个对象，不用为第二个请求接线。
- 关键的首屏图标。 当一个小 logo 是你的最大内容绘制（LCP）的一部分，而你想从关键路径上削掉一次请求时，内联能帮上忙。重点在于「小」。
这几种情况有个共同点：资产都是随着别的东西一起传递的，否则它就得有自己专属的投递渠道。邮件没法指望你的 CDN，bookmarklet 没有第二个文件可抓，JSON 响应是单一载荷。在这些场景里，内联的替代方案不是「一个缓存文件」，而是「一张缺失的图片」，这就彻底改变了算账方式。所以判断 Base64 是否适合，真正要问的不是「它小不小」，而是「这里到底有没有单独文件这个选项」。
何时不该内联：缓存、懒加载与 Core Web Vitals
反面这一节更长，因为内联会悄悄禁用好几样浏览器本来做得很好的事。
你失去了独立缓存。 这对回访用户的伤害最大。普通图片在首次访问后就待在他们的缓存里，此后永远秒加载。内联图片没有独立的缓存条目，它每一次都随文档一起搭车，于是回访者一次又一次地付那份字节成本。
你失去了懒加载。 loading="lazy" 属性让浏览器把首屏之外的图片推迟到用户快滚动到它们时再加载。data URI 在 HTML 被读取的那一刻就被解析并「下载」了，根本没有可推迟的东西。内联一打首屏外的图片，你就把它们全都强塞进了初始加载里。
你放大了阻塞渲染的资源。 如前所述，CSS 里的 data URI 会撑大一个阻塞首次绘制的资源。那份样式表越大，页面空白停留的时间就越长。
移动端解码开销更大。 data URI 每次文档加载都要做一遍 Base64 解码，在低端手机上这点 CPU 开销会慢慢累积。更麻烦的是，这些字节根本进不了浏览器的磁盘缓存，所以一张重的内联图每次访问都得重新解码一遍，而普通文件只需缓存并解码一次。
这条建议会随时间变化，还有个历史原因。内联最初的理由在 HTTP/1.1 时代被反复强调，就是减少请求：每条连接一次只能抓取一个资源，所以一个有 40 个小图标的页面要付 40 次往返。HTTP/2 在单条连接上多路复用众多请求，改变了这一点，让额外的小文件变得很便宜。于是内联的最大收益（更少的请求）基本蒸发了，而它的代价（失去缓存、无法懒加载、更大的阻塞渲染文件）却留了下来。如果你读到一些对 Base64 雪碧图热情洋溢的旧文章，请对照你的站点今天实际跑的协议来掂量它们。
Core Web Vitals 视角
对 LCP（Largest Contentful Paint） 而言，内联是双刃剑。对于一张小的、位于首屏、本身就是 LCP 元素的图片，去掉一次请求能让 LCP 提前一点。但如果你内联一张大图，结果恰恰相反：你延迟了它所在的文档或样式表，把整页的 LCP 往后推。往哪个方向走，取决于大小阈值。
对 CLS（累积布局偏移） 来说，内联丝毫不改变核心规则：图片仍需显式的 width 和 height（或一个 aspect-ratio 盒子），好让浏览器在渲染前预留出空间。一个没有尺寸的 data URI，会和一个没有尺寸的远程图片一样发生布局偏移。
比内联更有效的杠杆，通常是缩小源文件。在编码前先压缩图片，能让文件本身和由它产生的任何 data URI 都更小。浏览器与 Node 图片压缩指南讲了如何在客户端或构建步骤中做到这点，WebP、AVIF 与 JPEG 对比能帮你挑一个本就够小的格式。
如何在 HTML、CSS、Markdown 和 JSON 中内联图片
有了 data URI 之后，下面是它在各个场景中的落地方式，也正是图片转 Base64 转换器为你生成的四个即贴即用片段。
HTML——把 URI 粘进任意 src：
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…" alt="logo">CSS——用 url() 包起来作为 background-image（这就是经典的 base64 image in CSS 写法）：
.icon {
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");
}Markdown——用于 README、GitHub issue 和无法托管文件的 notebook 中的自包含图片链接：
JSON——API 或配置载荷中的内嵌资产：
{ "icon": "data:image/png;base64,iVBORw0KGgo…" }这四种在任何接受 URL 的地方都能用：img src、CSS background、mask-image，甚至网站图标的 <link>。每个现代浏览器都支持 data: 方案。
快速生成这些片段
手工拼这些容易出错：MIME 类型写错一个、或者混进一个多余的换行，图片就会悄无声息地渲染失败。把你的文件丢进图片转 Base64 转换器，它会生成全部四种片段、各配一个复制按钮，外加确切的体积增幅，让你一开始就知道这个资产到底该不该内联。
SVG：Base64 通常败下阵来的特例
SVG 打破了通常的逻辑，因为 SVG 是文本，不是二进制。Base64 存在的意义是让二进制数据变得文本安全，可 SVG 本身就是 XML 文本。把它编码成 Base64 只是给一个本不需要编码的字符串增重，还顺手让它变得不可读。所以单就 SVG 而言，Base64 几乎总是错误的选择。
对比内联同一个图标的三种方式：
/* 1. Base64 数据 URI——给本不需要编码的文本加上 33% 的开销 */
.a { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…"); }
/* 2. URL 编码的数据 URI——只对少数几个字符做百分号编码，没有 33% 开销 */
.b { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…%3C/svg%3E"); }
/* 3. 直接在 HTML 中内联 <svg>——可完全用 CSS 设样式 */<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
<path d="M12 2 L22 22 H2 Z" fill="currentColor" />
</svg>方式 2（URL 编码）通常比方式 1 更小，保持人类可读，并且压缩得更好。你只对那些会破坏 URI 的字符做百分号编码，比如 <、>、# 和引号，其余保持可读。URL 编码/解码的做法在工具内有说明；只在构建流水线明确要求时，才动用 Base64 SVG。
为何内联的 <svg> 常胜过 Base64 的 PNG 图标
如果你在 Base64 编码的 PNG 图标和内联 <svg> 之间抉择，SVG 通常在每个维度上都赢。它能缩放到任意大小而不模糊，不带 33% 的开销，而且能用 CSS 给它设样式、加动画、用 currentColor 重新着色，这是任何 data URI 都做不到的。Base64 的 PNG 则是一个固定分辨率的 blob，编码之后就再也碰不得。栅格 Base64 留给你确实需要内联一张照片或栅格截图的情况。
反向操作：从 Base64 还原成图片
反过来的问题同样常见：你拿到一段 Base64 字符串，可能来自 API 响应、一行日志、一个数据库字段，或一份你正在调试的样式表，而你需要看到那张真实的图片。
有两个细节常把人绊倒。第一是裸 Base64 与完整 data URI 的区别。一个完整的 data URI（data:image/png;base64,…）自带 MIME 类型，一个裸载荷（iVBORw0KGgo…）则没有。要渲染裸载荷，你要么自己补上正确的 data: 前缀，要么让工具从开头的字节推断格式：iVBORw0KGgo 表示 PNG，/9j/ 表示 JPEG，R0lGOD 表示 GIF。
第二是换行折行。来自邮件或较老工具的 Base64 常按 RFC 2045 每 76 个字符折一行。这些换行必须在解码前去掉，否则该字符串在 HTML 属性或 url() 中是无效的。
在浏览器里，你可以把一个完整的 data URI 直接交给 <img>：
<img src="data:image/png;base64,iVBORw0KGgo…" alt="decoded">在服务端，Node 从载荷重建文件：
import { writeFileSync } from "node:fs";
const b64 = "iVBORw0KGgoAAAANSUhEUgAA…"; // 裸载荷，无 data: 前缀
writeFileSync("output.png", Buffer.from(b64, "base64"));如果想要无需写代码的路径，粘贴一段字符串（带不带前缀、有没有换行都行）、预览它、读出它的尺寸和 MIME 类型，再下载一张真实的 PNG、JPG、GIF 或 SVG，就用 Base64 转图片转换器。它会去掉空白字符、容忍缺失的前缀，并自动从魔术字节检测格式。
对一张解码出的图片值得做一项理智检查：看看它报告的尺寸。如果你从一个含多张图的文件里抽出了一段字符串，而结果是 1×1，那你多半抓到的是一个追踪像素，而不是你想要的资产。还要记住，解码纯粹是机械且无损的：一张 Base64 的 PNG 会原样、逐字节地还原成同一张 PNG，没有任何重新压缩。一路上唯一变过的只是容器，出去时是文本字符串，回来时是二进制文件。
常见问题
我该把图片都转成 Base64 吗？
只在值得时才转：小（约 2 KB 以内）、几乎不变、且省下一次 HTTP 请求很要紧的图标或 logo，外加 HTML 邮件、自包含 widget 和 JSON 载荷。大图或任何跨页复用的图，几乎总该保留为普通文件，这样才能留住缓存和懒加载。
Base64 会让图片大多少？
约 +33%。Base64 把每 3 字节二进制编码成 4 个 ASCII 字符，再加少量 padding 和 data: 前缀。一张 9 KB 的 PNG 大约会变成 12 KB 文本。想把图片转成 Base64并看到你这张图的确切增幅，工具会在它的元数据栏里报告精确数字。
Base64 会让图片加载更快吗？
对一张极小的首屏图标，能，靠省下一次请求的往返。对较大或跨页复用的图片，它通常更慢：你失去独立缓存，无法懒加载，而把它内联进 CSS 还会撑大一个阻塞渲染的资源。大小是决定性因素。
我能在 CSS 里用 Base64 图片吗？
能：background-image: url("data:image/png;base64,…")。用于极小图标没问题。只要记住这个 data URI 会成为样式表的一部分，所以 CSS 一变整份文件就重新下载，而且图片无法与它分开缓存。
图标该用 SVG 还是 Base64？
优先用内联 <svg> 或 URL 编码的 SVG data URI。SVG 是文本、缩放干净、不带 33% 开销，所以通常比 Base64 PNG 更小，而且你能用 CSS 给它设样式。只在确实需要栅格图标时才动用 Base64。
怎么把 Base64 字符串还原回图片？
在浏览器里，把一个完整的 data:image/…;base64,… URI 放进 <img src>。在服务端，用 Buffer.from(b64, "base64") 写出文件。裸载荷需要补上 data: 前缀，折了行的字符串需要先去掉换行。Base64 转图片工具能搞定这一切，并让你下载结果。