图片转 Base64
图片转 data URI 字符串可复制，也支持 Base64 还原成图片预览
图片不会上传，本地转换。
图片转 Base64（data URI）：什么时候该内联，什么时候不该
data URI 的结构
转换结果是一个 data URI，结构如下：
data:[媒体类型][;base64],数据
| 例子 | 说明 |
|---|---|
data:image/png;base64,iVBORw0... | PNG 图片 |
data:image/svg+xml;base64,PHN2Zy... | SVG，用 base64 编码 |
data:image/svg+xml,<svg ...> | SVG 直接用 URL 编码（体积更小，见下） |
它可以出现在任何接受 URL 的地方：<img src="...">、CSS 的 background-image、favicon、甚至 fetch() 的参数。浏览器会把它当成一个内联资源直接使用，不发起额外请求。
代价一：体积增加约 33%
Base64 用 4 个字符表示 3 个字节，所以编码后体积变为原来的 4/3 ≈ 133%。一张 100 KB 的图片变成约 133 KB 的文本。
如果服务端启用了 gzip 或 brotli，HTML/CSS 里的 Base64 内容能压掉一部分（Base64 的字符集有限，压缩率大约 25%~30%），所以实际传输体积增量会小于 33%——但仍然比直接传二进制图片更大。
代价二：失去独立缓存
这是比体积更重要的问题，也是最容易被忽略的：
| 外部图片 | 内联 data URI | |
|---|---|---|
| 缓存单位 | 图片文件本身 | 整份 HTML/CSS 文档 |
| 改图片 | 只重下图片 | 包含它的整个文档都要重下 |
| 多页面使用 | 只下载一次 | 每个页面各存一份 |
| 首屏请求数 | 多一个请求 | 少一个请求 |
所以内联的收益是"减少请求数"，代价是"缓存粒度变粗、跨页重复"。在 HTTP/2 下多个请求可以复用同一个连接、并发传输，"减少请求数"这个收益已经大幅缩水——这是内联在现代站点里比十年前更少被推荐的原因。
代价三：不能用响应式图片
内联之后就没有独立的资源 URL，所以这些能力全部失效：
srcset与sizes：无法为不同分辨率提供不同图片，移动端也得下载为桌面准备的那一份。<picture>与格式协商：无法按浏览器支持情况选择 WebP/AVIF。- 懒加载（
loading="lazy"）：内联资源随文档一起到达，没有延迟加载的余地。 - CDN 的图片优化（自动压缩、裁剪、格式转换）。
这几条加起来意味着：对首屏关键的小图标有价值，对内容图片是明显的倒退。
什么时候该内联
| 场景 | 建议 | 理由 |
|---|---|---|
| 小于约 2-4 KB 的图标 | 内联 | 省掉一次请求的收益超过体积损失 |
| 只在某一页出现的装饰性图形 | 内联 | 不会被其他页面复用，缓存粒度问题不存在 |
| 必须保证"图片和页面同时到达" | 内联 | 例如邮件、离线单文件页面 |
| HTML 邮件 | 内联或外链（视客户端） | 邮件客户端对图片的处理差异大 |
| 内容图片、商品图、博客配图 | 不要内联 | 体积大、需要响应式、需要 CDN 优化 |
| 会被多个页面复用的图标 | 不要内联 | 会被复制进每个页面，总体积翻倍 |
| 大图、背景图 | 不要内联 | 33% 的体积增量不可接受 |
SVG 的额外技巧
SVG 是文本格式，所以它其实不一定要用 base64——直接用 URL 编码（只转义 # < > 等少数字符）通常能得到更短的结果，因为 base64 会把 3 字节变成 4 字符，而明文里大量字符不需要转义。
但要注意：URL 编码形式的 SVG 里，# 必须转成 %23（否则会被当作片段标识符），引号也要处理。这是"SVG 直接内联导致图片不显示"的原因。
工具怎么用
把图片拖进工具或点选择文件，得到可复制的 data URI；下方也可以把 Base64 字符串粘贴回来，还原成图片预览并下载。
还原时如果只粘贴纯 Base64 内容（不带 data: 前缀），工具会自动补上 data:image/png;base64, 再预览——但这假设了格式是 PNG。如果原始是 JPEG 或 WebP，还原出来的图片虽然能显示，但 MIME 类型不对，下载后的扩展名也会不匹配。需要精确还原时应该保留完整的前缀。
整个转换在浏览器本地完成，图片不会被上传——这一点对处理客户素材、内部截图、含有个人信息的图片是必要的。
常见问题
还原时只粘贴纯 Base64 行吗？
可以，工具会自动补上 data: 前缀再预览和下载。