文件转成 Base64 后为什么变大？变大了多少？

变大的是字符数，不是文件本身。Base64 把每 3 个字节写成 4 个字符，所以纯编码部分是原来的 4/3，约多 33%。实测把 92,811 字节的 PNG 转成 Data URL，输出 123,770 个字符，比原文件多 30,959 个字符；其中还有 22 个字符是 data:image/png;base64, 这段前缀。

Base64 转回文件后打不开是什么原因？

多数是扩展名丢了。带 data:image/png;base64, 这类前缀时，工具会按前缀里的类型自动填扩展名（png、txt 等），下载出来是 file.png；只粘裸 Base64 时前缀里没有类型，扩展名一栏是空的，下载出来的文件就叫 file、没有后缀，系统不知道该用什么程序打开。实测裸 Base64 还原的字节与原文件一致，只是需要手动补扩展名。

为什么把 Base64 粘进去提示「不是合法的 Base64 字符串」？

常见是串里带换行或空格。实测把 240 个字符的 Base64 按 72 列折行后粘贴，工具直接报错；在串中间插一个空格也同样报错。这个工具不自动清洗空白字符，从邮件、日志或长文本编辑器里复制后要先把换行和空格去掉再粘。

Data URL 里的 data:image/png;base64, 这段是什么意思？

前缀声明「这是什么类型的数据、用什么编码」。data: 后面跟 MIME 类型（image/png、text/plain），分号后面跟 base64 表示内容是 Base64 编码，逗号之后才是真正的数据。同一份内容换类型，前缀长度也不同：PNG 的前缀是 22 个字符，text/plain 的是 23 个字符。

图片转 Base64 塞进网页好不好？

只适合很小的资源，比如几 KB 的图标。好处是少一次请求；代价是体积多出约 1/3，而且这段内容跟着 HTML 或 CSS 一起下载，不能被浏览器单独缓存，也没法单独更新。大图内联会让首屏传输量明显变大，通常还是用独立的图片文件更划算。

邮件附件为什么也是 Base64？

因为邮件协议最初只保证传输 7 位 ASCII 文本，二进制文件必须转成可打印字符才能安全通过。MIME 标准（RFC 2045）规定的编码方式就是 Base64，所以附件在邮件里会膨胀约 1/3。

文件转 Base64 后为什么大了 1/3？Data URL 内联、还原成文件与换行报错

文件转 Base64 之后「变大」，变的是字符数，不是文件本身。Base64 把每 3 个字节写成 4 个字符，纯编码部分就多出约 1/3；再加上 data:image/png;base64, 这样的前缀，最终字符串还会更长一点。下面这些数字，都来自同一台机器在宝塔拨测的文件 / Base64 互转工具上的一次运行。

变大了多少：92,811 字节的 PNG，转出 123,770 个字符

上传一张 92,811 字节的 PNG 截图，页面显示的尺寸是 90.64 KB，类型 image/png，转换结果是一个完整的 Data URL：

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

文件转 Base64 工具：上传 90.64 KB 的 PNG，输出 data:image/png;base64, 开头的 Data URL

把输出框的内容量一下：123,770 个字符。比原文件的 92,811 字节多出 30,959 个字符，约 33%。

账可以拆得很清楚：

92,811 字节 = 30,937 组 × 3 字节，正好整分组，不用补 =
每组 3 字节写成 4 个字符，纯编码部分 30,937 × 4 = 123,748 个字符
再加上 data:image/png;base64, 这 22 个字符的前缀，合计 123,770

所以「Base64 让文件大了三分之一」这句话，说的是编码后的字符串长度。原始文件的字节一个没多，只是换了一种写法。

前缀里写的是什么类型，还原时就靠它

Data URL 的结构是 data:<MIME 类型>;base64,<数据>。前缀变了，长度也跟着变：

1×1 的 PNG，69 字节 → data:image/png;base64, + 92 个字符 = 114 个字符
一段 32 字节的纯文本 → data:text/plain;base64, + 44 个字符 = 67 个字符

两者的差别不只是类型名：image/png 占 9 个字符，text/plain 占 10 个字符，所以前者前缀 22 个、后者 23 个。前缀的作用是告诉下游「这段数据还原出来是什么」，浏览器、邮件客户端、接口都靠它决定怎么处理。

还原成文件：带前缀能自动识别，裸串只能自己补后缀

切到「Base64 转文件」，另取一张 64×64、179 字节的测试 PNG（与前面两张不是同一个文件），把它的 Data URL 粘进去，工具会做三件事：把扩展名自动填成 png、在预览区把图片画出来、允许下载。

Base64 转文件工具：带 data: 前缀时扩展名自动填成 png，预览区显示还原出的图片

实测下载下来的是 file.png，179 字节，与该测试 PNG 逐字节一致。换成 data:text/plain;base64, 开头的串，扩展名会自动变成 txt，下载得到 file.txt，32 字节，同样与原文件一致。

不带前缀、只粘裸 Base64 就不一样了。用同样 44 个字符的文本 Base64 试：扩展名一栏保持空的，预览区提示「无可预览的图片内容」，下载出来的文件直接叫 file，没有后缀。字节内容其实没问题（实测 32 字节与原文件一致），但双击时系统不知道这是文本、图片还是压缩包，表现就是「打不开」或者被当成未知文件。手填扩展名 txt 后再下载，得到 file.txt，32 字节同样与原文件一致。

所以还原失败时先看两处：字符串是不是以 data: 开头，扩展名一栏是不是空的。补上前缀或手填扩展名，文件就能正常打开。

中间有换行或空格，会直接判为不合法

从邮件正文、日志或者折过行的配置里复制 Base64，很容易带上换行。实测把 240 个字符的 Base64 按 72 列折成 4 行再粘贴，工具直接标红：

Base64 转文件工具：Base64 中间带换行时提示「不是合法的 Base64 字符串」

在串中间插一个空格也一样报错。这个工具不做事先的空白清洗，粘贴前先把换行、空格去掉。有些解码器会自动忽略空白字符，但依赖这个行为容易在换工具时踩坑——按标准 Base64 的字母表，空白本来就不在字符集里。

什么时候值得内联，什么时候不值得

图片转成 Data URL 直接写进 HTML 或 CSS，最直接的好处是省掉一次 HTTP 请求，但它只在很小的资源上划算：

几 KB 的图标、logo：内联后节省一次请求，收益能覆盖体积增加
大图、照片：体积多出约 1/3，而且这段内容跟着页面一起下载，浏览器不能单独缓存它，改图就得改样式或模板
接口调试：临时把一张小图塞进 JSON 字段发给后端，比让对方找文件快

页面上写明「所有转换均在浏览器本地完成，不会上传到服务器」，这一点对处理内部截图、客户资料比较重要——转换过程本身不经过网络。

邮件附件也是 Base64，原因在协议

邮件最初只保证传输 7 位 ASCII 文本，二进制文件直接发会被截断或破坏。MIME 标准（RFC 2045）的做法是先按 Base64 编码成可打印字符，再放进邮件正文，接收端解码还原。所以附件在邮件里的体积会比原文件大约多 1/3，这也是为什么邮件的容量限制和附件实际大小经常对不上。

一句话总结：Base64 只换写法、不加保护，代价是长度变成原来的 4/3；能不能正确还原，取决于前缀里的类型和后缀有没有跟着一起过去。