Base64 字符串或 Data URI

使用方法

1. 将 Base64 编码的图片字符串粘贴到输入区。可以包含 data:image/… 前缀，也可以只是原始 Base64 数据。
2. 点击解码图片以预览。
3. 点击下载图片将其保存为 PNG 文件。

常见问题

支持哪些 Base64 格式？

您可以粘贴原始 Base64 字符串（工具会自动识别格式），也可以粘贴完整的 Data URI，如 data:image/png;base64,iVBOR…。支持的图片类型：PNG、JPEG、WebP、GIF、BMP 和 SVG。

有大小限制吗？

没有严格限制，但非常大的 Base64 字符串（超过 5–10 MB）根据您的设备可能需要一些时间处理。

如何把图片编码为 Base64？

使用我们的图片 → Base64 转换器，免费 · 只需拖入图片即可得到其 Base64 字符串。

Base64究竟是什么

Base64是定义于RFC 4648（2006年10月）的二进制转文本编码方案。它使用一个64字符字母表：A-Z、a-z、0-9，加上+和/，将任意字节表示为可打印ASCII。每三字节二进制输入恰好产生四字符输出，因为6位（一个Base64字符）和8位（一字节）的最小公倍数是24。这个四比三的比例也解释了为何Base64编码的文件比原始二进制大约大33%。

当输入长度不是三的倍数时，Base64使用=填充，使输出始终是四字符的倍数：一个末尾字节产生两个字符加==；两个末尾字节产生三个字符加=。某些编码器会去掉填充，因此健壮的解码器需要在将字符串传递给atob()之前重新添加填充。

RFC 4648还定义了一个URL安全变体（有时称为base64url），将+替换为-，将/替换为_。JWT使用它。本解码器规范化两种字母表，您无需关心收到的是哪种。

Data URI方案

RFC 2397（1998年8月）定义了data: URL方案。完整语法为：

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

一个典型的内联PNG看起来像data:image/png;base64,iVBORw0KGgo…。;base64令牌是一个标记（注意没有=符号），告知浏览器从Base64解码载荷，而不是将其视为百分比编码文本。如果省略;base64，数据被解释为URL编码文本。如果完全省略媒体类型，规范默认使用text/plain;charset=US-ASCII。

本解码器接受两种形式：粘贴完整的data URI或仅粘贴Base64载荷。当只提供载荷时，格式从首个解码字节检测，见下文。

如何检测格式

如果您粘贴不带data:image/…前缀的原始Base64字符串，判断图像类型的唯一方法是查看前几个解码字节，每种常见图像格式都以可识别的签名开头，正式称为「魔数」。浏览器在嗅探MIME类型时也做完全相同的检查（该过程在WHATWG MIME嗅探标准中规定）。捷径在于这些签名转换为可预测的Base64前缀：

格式	首字节（十六进制）	Base64前缀
PNG	89 50 4E 47 0D 0A 1A 0A	iVBORw0KGgo
JPEG	FF D8 FF	/9j/
GIF89a	47 49 46 38 39 61	R0lGODlh
WebP	52 49 46 46 … 57 45 42 50	UklGR
BMP	42 4D ("BM")	Qk
SVG（XML文本）	以<?xml或<svg开头	PD94bWwg或PHN2Zw

PNG的签名是格式库中最巧妙的之一。89字节设置了最高位，这样仅支持7位的邮件中继器会明显破坏它。接下来三个字节以ASCII拼出PNG，所以对文件运行head的人可以识别它。随后是DOS行尾（0D 0A），一个MS-DOS Ctrl-Z字符（让旧版TYPE命令停止进一步打印），以及Unix换行符（0A），它们共同检测每种「帮倒忙」地改写行尾的常见传输方式。

Base64图像的来源

大多数使用此类工具的人都在调试某些问题。常见情况：

• JSON API响应。JSON没有原生二进制类型，因此API将图像、签名PDF、头像和上传的截图作为Base64字符串嵌入JSON字段。在此粘贴该值即可查看实际内容。
• CSS和打包资产。Webpack和Vite有一个小型资产阈值（Vite默认为4 KB），会自动将小图像以data URI形式内联到打包的CSS或JS中。调试「这个图标从哪来？」时，data URI就落到这里。
• HTML邮件签名。Gmail、Outlook和Apple Mail将签名图像作为data URI内联，以确保图像在转发时存活。设计师有时需要取回原始logo。
• CMS和Notion导出。WordPress XML导出、Notion导出和Confluence备份将缩略图以Base64内联嵌入，以保持导出的自包含性。
• 二维码和签名板。生成二维码（qrcode.js）或捕获手写签名（signature_pad）的浏览器库通常将输出暴露为data:image/png;base64,…字符串。
• 服务器端PDF生成。Puppeteer、openhtmltopdf和iText等工具接受带内联data URI的HTML。当logo「没有出现」在渲染的PDF中时，解码URI是最快速查看这些字节是否是图像的方法。

是否应该将图像内联为Base64？

这个权衡过去更有趣。在HTTP/1.1下，每张图像都是独立的阻塞请求，内联一个小图标可以节省真实的往返时间。在HTTP/2和HTTP/3下，这个理由已大幅收窄。诚实总结：

您获得：零额外HTTP请求、原子交付，以及无需外部依赖即可工作的自包含文件（单文件演示、电子邮件、服务器渲染PDF）。

您失去：浏览器无法单独缓存内联data URI，因此十个页面上的相同图像会随每次HTML响应重新下载。编码资产比二进制等效版本大约大33%。CDN无法对跨页面嵌入的图像进行去重。图像优化管道（Cloudinary、Vercel、Next.js <Image>）无法对内联资产进行检查、压缩、调整大小或提供AVIF或WebP等现代格式。浏览器还必须先解码Base64再解码图像，这在每次渲染时都需要额外的CPU开销。

合理的经验法则：将小于约4 KB且只在一处使用的图像、单像素占位符，以及需要在自包含文件中传输的图像内联。不要内联在多个页面使用的任何内容、大于约4 KB的任何内容、应该懒加载的任何内容，或者受益于格式协商的任何内容。

安全性：Base64不做的事

Base64是编码，不是加密。RFC 4648 §12明确警告它「在视觉上隐藏」数据，但不提供「计算保密性」，任何人都可以立即解码。不要认为Base64编码密码或API密钥是一种安全措施。

两个值得了解的安全细节：

• 在现代浏览器中，顶级导航到data: URL已被阻止（在新标签页中打开不起作用），以减轻利用data URI渲染虚假登录页面的网络钓鱼攻击。子资源使用（<img src="data:…">、CSS url(data:…)）仍被允许。
• SVG是特殊情况。SVG是XML，SVG文档可以包含<script>元素和事件处理器。将SVG加载到<img>标签是安全的（浏览器使用禁用脚本的渲染器），但将同一SVG加载到<object>或<iframe>可能执行任意JavaScript。本解码器始终只设置<img src>，这是安全路径。如果您从不可信来源解码了SVG，请像对待任何其他不可信文档一样对待该文件。

更多问题

为何我的Base64字符串以「InvalidCharacterError」报错？

三个常见原因：复制粘贴时产生的空白符或换行符（旧版MIME Base64规范在76个字符处换行，JavaScript的atob()会拒绝）；使用-和_替代+和/的URL安全Base64；或去掉了末尾的=填充导致长度不是四的倍数。本解码器会清理空白符、规范化字母表并重新填充后再解码，但非常损坏的字符串仍会失败。

解码时会损失质量吗？

不会。解码是编码的精确逆过程，您会逐字节获得原始图像。下载的格式就是Base64中的格式（PNG、JPEG、WebP、GIF、BMP或SVG），没有重新编码步骤。

浏览器能接受的最大data URI是多大？

根据MDN，Chromium和Firefox的当前限制约为512 MB，Safari/WebKit约为2 GB。实际上，瓶颈是内存和CPU而非URL规范，超过约10 MB的粘贴在普通笔记本上开始感觉迟缓。

有任何内容会发送到服务器吗？

不会。解码完全在浏览器中通过原生atob()函数和赋给Blob或分配给<img>标签的data URI进行。不会上传任何内容；页面加载后可离线工作。

为何每个JPEG的Base64都以/9j/开头？

几乎所有JPEG文件都以字节FF D8 FF（图像起始标记后跟另一个标记字节）开头。将三个字节（全为FF夹着D8）进行Base64编码时，位模式11111111 11011000 11111111被分为6位组111111 111101 100011 111111：Base64字母表位置63、61、35、63，拼出/9j/。随后的第四个字符因跟随的标记而异（E0对应JFIF，E1对应Exif），但前三个字符是通用的。

相关工具