Question 1

Base64 是什么？

Accepted Answer

Base64 是一种二进制转文本的编码方案。它把任意二进制数据——比如文件的字节——转换成由 64 个可打印 ASCII 字符（A–Z、a–z、0–9、+、/）组成的字符串。编码后的结果可以安全地在 JSON、HTML、邮件、HTTP 头等文本协议中传输。

Question 2

Base64 是加密吗？

Accepted Answer

不是。Base64 是编码，不是加密。任何人都能立刻解码，没有密钥，没有任何保护。永远不要用 Base64 来隐藏敏感数据——它只是一种把二进制表示为文本的方式。

Question 3

Base64 安全吗？

Accepted Answer

用于在文本协议中传输数据是安全的。但 Base64 本身没有任何保密性——任何看到字符串的人都能立刻解码。如果需要保护数据，应使用 AES、RSA 等真正的加密算法，而不是 Base64。

Question 4

为什么 Base64 比原始文件更大？

Accepted Answer

Base64 每次编码 3 个字节，输出 4 个字符。由于每个字符占 1 字节，输出大小是输入的 4/3，约大 33%。如果输入字节数不是 3 的倍数，还会追加 = 填充符，小文件的额外开销略高于 33%。

Question 5

Base64 用的 64 个字符是哪些？

Accepted Answer

A–Z（26 个）、a–z（26 个）、0–9（10 个）、+ 和 /（2 个），共 64 个。= 是填充符，不属于这 64 个但会出现在输出中。Base64URL 把 + 换成 -、/ 换成 _，以便在 URL 中直接使用。

Question 6

Base64 和 URL 编码有什么区别？

Accepted Answer

Base64 把二进制数据转换为 64 字符的 ASCII 文本，解决的是"二进制如何变成文本"的问题。URL 编码（百分号编码）把 URL 中的特殊字符转换为 %XX 形式，解决的是"URL 里的特殊字符如何安全传输"。两者目的不同，互不替代。

Question 7

什么是 Base64URL？

Accepted Answer

Base64URL 是 Base64 的 URL 安全变体：把 + 换成 -，/ 换成 _，通常省略 = 填充。这样生成的字符串可以直接放进 URL、文件名或 HTTP 头，无需再做百分号编码。JWT 的 Header 和 Payload 就用 Base64URL 编码。

Question 8

怎么把文件转换为 Base64？

Accepted Answer

打开"文件转 Base64"工具，把文件拖进上传区，选择需要的输出格式（原始 Base64、Data URI、HTML img 标签、CSS、JSON、API 载荷），然后复制结果。所有处理都在浏览器本地完成，文件不会上传到服务器。

Question 9

怎么把 Base64 解码还原为文件？

Accepted Answer

把 Base64 字符串或 Data URI 粘贴到"Base64 转文件"工具。工具会从 Data URI 前缀自动识别 MIME 类型，或者手动选择文件类型，然后点击"下载"即可保存还原的文件。

Question 10

哪些文件类型可以 Base64 编码？

Accepted Answer

所有文件都可以。Base64 把文件当作纯二进制数据处理，不关心格式——图片、PDF、字体、音频、视频、压缩包、可执行文件，全部支持。MIME 类型是附在 Data URI 前缀里的元数据，告诉接收方如何解读这段数据。

Question 11

浏览器里 Base64 编码的文件大小有限制吗？

Accepted Answer

没有硬限制，但文件超过 10 MB 就会明显变慢。浏览器需要同时在内存中保存原始 ArrayBuffer 和 Base64 字符串，而输出比输入大 33%，内存峰值约是原文件的 2.3 倍。大文件推荐用 multipart/form-data 上传或对象存储直传代替 Base64。

Question 12

可以把字体内嵌到 CSS 里吗？

Accepted Answer

可以。在 CSS 里用 @font-face { src: url(data:font/woff2;base64,…) format("woff2"); } 直接内联字体，省去字体文件的 HTTP 请求。适合小字体子集；完整字体文件通常 200 KB 以上，内联会让 CSS 变得很大，不推荐。

Question 13

图片可以存成 Base64 吗？

Accepted Answer

可以。Base64 图片可以直接内嵌到 HTML（<img src="data:image/png;base64,…">）或 CSS（background-image: url(data:…)），不需要单独的 HTTP 请求。适合 5–10 KB 以内的小图标；大图会让页面体积膨胀，而且无法独立被浏览器缓存。

Question 14

什么是 Base64 Data URI？

Accepted Answer

Data URI 是一种把文件内容直接内嵌到 URL 里的格式：data:[mime];base64,[Base64 字符串]。例如 data:image/png;base64,iVBORw0K… 浏览器可以直接把它渲染成图片、PDF 或其他支持的类型，不需要发 HTTP 请求。

Question 15

什么时候用 Base64 图片，什么时候用外链 URL？

Accepted Answer

小图标（< 5 KB）且只在当前页面用一次 → 用 Base64，省一个 HTTP 请求。大图、多页面共用的图片、需要 CDN 缓存的资源 → 用外链 URL。Base64 图片嵌在 HTML 里，无法被浏览器单独缓存，每次加载页面都要重新传输。

Question 16

我的 Base64 文件该用哪个 MIME 类型？

Accepted Answer

用与文件格式匹配的 MIME 类型：PNG 用 image/png，JPEG 用 image/jpeg，SVG 用 image/svg+xml，PDF 用 application/pdf，WOFF2 字体用 font/woff2。MIME 类型写在 Data URI 前缀里，告诉浏览器或 API 如何处理这段数据。

Question 17

SVG 可以转 Base64 吗？

Accepted Answer

可以，编码后得到 data:image/svg+xml;base64,… 格式的 Data URI，可以放进 HTML 或 CSS。不过 SVG 本身是文本，也可以用 URL 编码的形式（data:image/svg+xml,[URL 编码的 SVG]），对于小型 SVG 有时比 Base64 更短。

Question 18

应该用 Base64 在 API 里传文件吗？

Accepted Answer

要看文件大小。小文件（< 1 MB）用 Base64 放进 JSON 很方便，不需要处理 multipart 边界。大文件推荐 multipart/form-data——没有 33% 的体积膨胀，支持流式传输和进度跟踪，服务器处理效率也更高。

Question 19

怎么在 JSON API 请求里发送 Base64 文件？

Accepted Answer

把 Base64 字符串作为 JSON 字段值传入。很多 API 同时要求传 MIME 类型：{ "file": "[Base64]", "mimeType": "image/png" }。用"API 专用 Base64"工具可以直接生成包含 JS、cURL、Python、PHP 示例的完整请求载荷。

Question 20

编码前怎么预估 Base64 大小？

Accepted Answer

公式：⌈原始字节数 / 3⌉ × 4 个字符。100 KB 的文件 Base64 后约 137 KB。用"Base64 体积计算器"工具输入原始大小，可以精确计算编码后的体积，方便在决定用 Base64 前评估传输开销。

Question 21

HTML 邮件里可以用 Base64 图片吗？

Accepted Answer

可以，但有取舍。部分邮件客户端支持显示 Base64 内联图片；另一些会屏蔽或显示为破图。Base64 图片会大幅增大邮件体积，可能触发垃圾邮件过滤。对于投递率要求高的邮件，建议用 CDN 托管图片或 CID 附件方案。

Question 22

HTML 邮件里放图片最好用哪种方式？

Accepted Answer

三种方案：① 托管图片——链接到 CDN URL，投递率最好、邮件体积最小；② CID 附件——把图片作为 MIME 附件发送，HTML 里用 cid: 引用，兼容性好但实现复杂；③ Base64 内联——直接嵌入 HTML，离线也能显示，但体积大、可能被误判为垃圾邮件。

Question 23

JWT 为什么用 Base64URL 而不是 Base64？

Accepted Answer

JWT 令牌会出现在 URL、HTTP 头和 Cookie 里。标准 Base64 里的 + 和 / 在 URL 中是特殊字符，会被当作参数分隔符或路径分隔符。Base64URL 把它们换成 - 和 _，并去掉 = 填充，令牌可以直接放进 URL 不需要额外转义。

Question 24

怎么解码 JWT？

Accepted Answer

JWT 由三段 Base64URL 编码的内容用 . 分隔：Header.Payload.Signature。对前两段做 Base64URL 解码即可读取 JSON。第三段是加密签名，需要密钥才能验证——但不需要密钥就能读取 Header 和 Payload 的内容。用"JWT 解码器"工具可以一键解码。

Question 25

没有密钥也能读取 JWT 内容吗？

Accepted Answer

可以。JWT 的 Header 和 Payload 只是 Base64URL 编码，不是加密——任何人看到令牌都能立刻解码读取内容。签名只用来验证令牌没被篡改，但读取内容不需要签名密钥。因此，绝对不要在 JWT Payload 里存放密码、密钥等敏感信息。

Question 26

为什么会报"Invalid Base64"错误？

Accepted Answer

常见原因：① 字符串长度不是 4 的倍数——缺少 = 填充；② 包含 Base64 字母表之外的字符；③ URL 编码过的 Base64（+ 变成了 %2B，/ 变成了 %2F）；④ Base64URL 格式（含有 - 和 _）被标准解码器拒绝；⑤ 字符串里混入了空格或换行符。

Question 27

Base64 末尾的 = 或 == 是什么意思？

Accepted Answer

= 是填充符。Base64 每次处理 3 个字节，输出 4 个字符。如果最后一组只有 1 个字节，在末尾补 ==；只有 2 个字节，补 =。这确保输出长度始终是 4 的倍数，方便解码器正确处理。

Question 28

粘贴 JWT 或 URL 参数时，Base64 解码为什么失败？

Accepted Answer

JWT 和 URL 参数用的是 Base64URL，把 + 换成了 -、/ 换成了 _，并省略了 = 填充。标准 Base64 解码器遇到 - 和 _ 会报错。先把 Base64URL 转换为标准 Base64：把 - 换回 +，_ 换回 /，然后在末尾补 = 号直到长度是 4 的倍数。

Question 29

Base64 字符串看起来没问题，但解码失败，原因是什么？

Accepted Answer

检查隐藏字符：MIME 标准每 76 个字符自动插入换行（
），复制时可能一起带过来；字符串首尾可能有空格；或者带着 data:…;base64, 前缀没有剥掉。大多数 Base64 解码器很严格，一个多余字符就会失败。解码前先去掉空白和 Data URI 前缀。

Base64 常见问题

热门 Base64 工具