图片
图片转 Base64
内联图片能省掉一次 HTTP 请求，代价是体积大约多三分之一，而且无法单独缓存。图标这么做划算，照片这么做不划算。
把图片拖到这里，或点击选择。
怎么用
- 拖入或选择一张图片。
- 复制原始 data URI，或直接用 CSS、HTML 按钮。
- 留意体积比——接近 1.33 倍是 Base64 的正常值。
- 内联图片控制在 10 KB 以内才划算。
内联的真实代价
data URI 省掉一次 HTTP 请求，但让载荷大了约三分之一，无法单独缓存，还会阻塞包含它的样式表的渲染。在 HTTP/2 下，很多小请求本身很便宜，省下的那一次请求远不如十年前值钱。几 KB 以内的图标和占位图内联是划算的，照片类的东西内联就是亏。
它真正帮上忙的地方
单文件 HTML 导出、必须能经得起转发的邮件模板、以及必须在任何网络往返之前渲染出来的 CSS。这些场景的约束是可移植性，不是速度。一旦资源放在带长缓存头的 CDN 上，独立文件几乎总是更好的安排——浏览器只下一次，之后再也不下。
2 KB 法则，以及它为什么还成立
只有小体积、被重复使用的资源才值得内联：图标、logo、一个单色转圈动画。Base64 会让字节膨胀约 33%，而 gzip 补不回来——编码后的文本熵很高，几乎压不动，反观原 PNG 本来还留着大量冗余。超过大约 2 KB，多出来的字节就比省下的那次请求更贵。
另一个代价是缓存。内联的图片会随每个包含它的页面重新下载，无法单独缓存；独立文件只需取一次，之后全站复用，回访也能命中。
常见问题
为什么 Base64 版本更大？
Base64 把每三个字节映射成四个字符，体积自然涨约 33%。压缩也没用，因为数据已经是编码过的。
什么时候该内联？
小图标、logo、加载占位图这类「省一次请求比多几个字节更重要」的场景。超过 10 KB 左右，独立文件交给浏览器缓存更划算。
能用在邮件模板里吗？
很多邮件客户端会屏蔽 data URI，Outlook 尤其不渲染。还是把图片托管出去再引用链接。
文件会上传吗？
不会。转换由当前标签页里的 FileReader 完成，图片不会被传输。
能直接粘进 CSS 吗？
可以：background:url(data:image/png;base64,...)。控制在几 KB 以内，否则样式表本身就成了瓶颈。
为什么字符串比文件还长？
Base64 把三个字节映射成四个字符，所以文本恰好是二进制大小的 4/3，如果工具还加了换行，会更长。