图片 → Base64 转换器，免费

使用说明

1. 拖入或选择图片。浏览器通过 FileReader API在本地读取文件，不会上传至任何地方。
2. 编码器对字节进行转换，采用标准Base64字母表：每3个输入字节转为4个ASCII字符，取自 A-Z a-z 0-9 + /，当输入长度不是3的倍数时，末尾补至多两个 = 填充字符。
3. 复制所需内容。「复制Base64」给出纯编码字符串（适用于JSON载荷或后端处理）。「复制Data URI」给出完整的 data:image/png;base64,… 形式，可直接用于 <img src> 属性或CSS background-image: url(…)。
4. 粘贴到目标位置。输出为纯文本，适用于HTML、CSS、JSON、JavaScript、Markdown或任何可使用字符串的场合。

Base64的本质

Base64在 RFC 4648（2006年10月）中定义。编码每次取24位输入（三个字节），将其改写为4个6位索引，指向一个64字符的字母表。计算精确：3字节（24位）→ 4个字符（每个携带6位）。当输入长度不是3的倍数时，编码器追加 = 填充字符，使输出长度成为4的倍数。

两个实际影响：

• 输出始终比输入大约33%。4/3的比率是算法的根本特性。100 KB图片编码后约为133 KB。采用MIME风格的76字符换行时，开销接近37%。
• 输出在任何地方都文本安全。64字符字母表是所有常见ASCII文本通道的交集：HTML、JSON、XML、电子邮件、URL（使用URL安全变体）、源代码。这正是Base64存在的全部理由：在为文本而设计的系统中传输二进制数据。

RFC 4648 §12阐明了一个重要的非特性：「Base64编码从视觉上隐藏了本来容易识别的信息，如密码，但不提供任何计算机密性。」任何人都可以用任何语言的两行代码解码Base64字符串。它是编码，而非加密。

Data URI：内嵌图片形式

「data URI」是允许Base64字符串代替图片URL的包装格式。RFC 2397（1998年）定义了其语法：

data:[<mediatype>][;base64],<data>

对于图片，即 data:image/png;base64,iVBORw0KGgo… 用于 <img src> 属性，或CSS中的 background-image: url("data:image/svg+xml;utf8,<svg…>")。;base64 令牌告诉浏览器数据部分已编码；不带该令牌时，数据被视为百分号编码的文本。RFC 2397本身指出data URI「仅适用于短值」，这一提示已演变为严格的性能规则。

何时应将图片内嵌为Base64

• 单文件交付物。电子邮件签名中嵌入需要在转发时保持完整的logo。CodePen、JSFiddle或Bug复现报告所用的自包含HTML演示。生成的PDF中必须嵌入图片以确保文件可离线使用。
• 微小的关键路径图标。内嵌到关键CSS中的200字节箭头或加载动画，可能比触发独立的HTTP请求加载更快，在慢速连接上尤为如此。
• 内嵌JSON/API响应。头像上传、签名、OCR样本、生成的二维码，凡是API消费者期望字节内嵌而非通过独立URL获取的场合。
• 沙盒iframe或其他禁止外部资源加载的场景。
• 配置文件，不希望在JSON/TOML/YAML旁边放置独立图片文件时。

何时不应将图片内嵌为Base64

对于大多数生产网站，内嵌Base64图片比普通 <img> 引用更慢。有五个相互叠加的原因：

1. 33%的体积开销，始终如此。每个字节编码后变为4/3字节。gzip压缩后表面开销有所缩小（因为Base64本身具有重复性），但浏览器解析的字节仍比原始文件大33%。
2. 图片无法单独缓存。外部 image.png 只需获取一次，之后每个链接到它的页面均可复用。Base64图片存在于HTML或CSS内部，该文件每次发生变化都需要重新下载。
3. 拖慢HTML和CSS解析。渲染阻塞CSS中的长内嵌字符串会进一步推迟关键路径。Harry Roberts（CSS Wizardry）实测了一个真实客户样式表：含Base64图片时为925 KB，不含时为708 KB，gzip后分别为232 KB和68 KB。移除Base64使压缩后的CSS减少了70.68%。
4. 无法懒加载。loading="lazy" 属性会推迟获取图片，直到用户滚动到附近。Base64图片已经在文档中，没有什么可以推迟的。
5. HTTP/2和HTTP/3已解决「请求数过多」的问题。多路复用允许单个连接并行传输数百个文件，因此内嵌的最初理由基本已不成立。

来自Google PageSpeed和大多数性能专家的实用经验法则：仅当图片编码后小于约1-2 KB，且出现在关键CSS的首屏内容中时才内嵌。体积更大的内容作为独立文件几乎必然性能更好。

SVG：使用UTF-8编码，而非Base64

SVG本身已是文本，因此编码为Base64会无谓地浪费约33%的字节。更精简的形式是URL编码的UTF-8：

/* Base64 SVG (longer) */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");

/* URL-encoded SVG (shorter, also human-readable) */
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' …>");

大多数现代构建工具（PostCSS的 postcss-inline-svg、Webpack的 svg-url-loader）默认输出URL编码形式。对于内嵌SVG，除非特定消费者要求 ;base64，否则应优先使用该形式而非Base64。

本工具识别的MIME类型

data URI的媒体类型前缀告知消费者如何解读这些字节。浏览器根据您选择的文件自动检测：

隐私与安全注意事项

大多数在线「图片转Base64」网站会将您的文件上传至其服务器进行编码，再返回结果。这意味着预发布UI截图、受NDA保护的设计稿、儿童照片、医疗扫描件或合同签名会经过第三方基础设施。本工具在本地编码：浏览器的 FileReader 将文件读入内存，编码器在您的设备上以JavaScript运行，离开页面的唯一内容是您复制后的编码字符串。

如果您在生产环境中使用Base64图片，有两个内容安全策略注意事项值得了解：

• 内嵌Base64图片会绕过 img-src 规则，除非您明确允许。严格的CSP如 img-src 'self' 会拦截 data: URI。要允许它们，请写入 img-src 'self' data:。
• 同样适用于CSS内嵌背景图。如果CSP正在拦截您的内嵌背景，请先检查 img-src 指令。

常见错误

1. 将Base64视为混淆手段。它不是。任何人都可以用任何语言的两行代码解码它。不要将凭据、API密钥或敏感数据放入Base64字符串以「隐藏」它们。
2. 将200 KB的主图内嵌。图片编码后变为266 KB，卡在HTML中，无法单独缓存，无法懒加载，页面首次渲染明显变慢。请以普通文件方式提供。
3. 在需要Data URI时复制了原始Base64。裸露的Base64字符串放入 <img src> 属性会显示为破损图片，您需要 data:image/png;base64, 前缀。请使用「复制Data URI」按钮。
4. 将SVG进行Base64编码。SVG本身已是文本，改用URL编码可节省33%的开销。
5. 忘记CSP。严格的 img-src 'self' 会拦截data URI。如果您使用Base64图片，请在指令中添加 data:。
6. 尝试解码带有 data: 前缀的Base64字符串。data:image/...;base64, 部分是元数据，在将字符串传入Base64解码器之前请先去除它。
7. 将机密图片粘贴至服务器端编码器。如果URL显示「encode」但网络面板出现了POST请求，您的图片刚刚离开了您的设备。

常见问题

「Base64」和「Data URI」有什么区别？

Base64是编码本身（一个类似 iVBORw0KGgo… 的字符串）。Data URI是将Base64字符串转化为可替代图片URL的包装器：data:image/png;base64,iVBORw0KGgo…。该包装器告知浏览器媒体类型和编码方式，以便正确解读字节。本工具中的两个按钮分别提供这两种形式。

Base64安全吗？

不安全，这也不是它的用途。Base64是编码，而非加密。RFC 4648 §12明确指出：它「不提供任何计算机密性」。任何人都可以即时解码Base64字符串。如需保密，请先加密数据（如使用AES等），再对密文进行Base64编码以供传输。

图片最大可以多大？

本工具不设硬性限制，编码在浏览器内存中完成。实际上限取决于您的设备，现代笔记本通常可以处理数十MB。更大的限制来自消费端：许多电子邮件客户端、浏览器和API对data URI大小有各自的限制，内嵌超过几KB的内容在性能上几乎都不合算。

为什么我的Base64字符串比原文件大33%？

因为每个Base64字符携带6位，而每个输入字节携带8位。Base64能无余数表示的最小单元是3字节（24位 = 四个6位字符），因此输出比率恰好为4/3 ≈ 1.33。没有任何Base64变体能避免这一点，它在数学上已被固化于编码中。

编码后的图片能在HTML邮件中使用吗？

大多数情况下可以，但并非始终如此。Apple Mail、现代Gmail及大多数网页邮件客户端能正常渲染 data: 图片。微软Outlook桌面版对此支持一向不稳定，部分版本可正常渲染data URI，部分版本会完全忽略它们。在将Base64图片用于事务性邮件之前，请先在目标客户端列表中测试。为获得广泛兼容性，托管图片URL仍是更稳妥的选择。

应该使用base64url（用-和_）代替吗？

仅当编码数据放在URL或文件名中、+ 和 / 会需要百分号编码时才使用。对于HTML <img src> 属性和CSS background-image，标准字母表即可。RFC 4648 §5明确为URL/文件名场景定义了URL安全变体，并警告它「不应仅被称为「base64」」，以避免与标准字母表混淆。

相关工具