Base64 编码器和解码器

介绍

Base64 编码器和解码器是一款免费的在线工具，用于将文本转换为 Base64，并将 Base64 转换回文本。两种操作在您输入时实时进行，无需重新加载页面或点击提交按钮。该工具完全在浏览器中运行 — 没有任何内容发送到服务器。

同一页面上有两个独立的部分：一个用于编码，一个用于解码。每个部分都有自己的文本区域、上传区域和操作按钮，让您可以双向操作而无需切换模式。

什么是 Base64

Base64 是一种仅使用可打印 ASCII 字符表示二进制数据的方法。它不是加密或压缩方案 — 它旨在通过为文本设计的系统安全地传输二进制数据。

编码原理

Base64 字母表使用 64 个字符：

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

编码过程将输入分成每组 3 个字节（24 位），然后将每组分成四个 6 位值。每个 6 位值（0–63）映射到字母表中的一个字符。

输入：       F   o   o
二进制：     01000110 01101111 01101111
6 位分组：   010001 100110 111101 101111
十进制：     17     38     61     47
Base64：    R     b    9     v

"Foo" 被编码为 Rm9v。

为什么是 64

选择 64 是因为它是仅使用几乎所有字符集中都可用字符（字母、数字和两个标点符号）的最大 2 的幂。这使得 Base64 在可能会损坏或拒绝非 ASCII 字节的电子邮件系统、JSON 负载、URL 和其他基于文本的通道中保持可靠。

每个 Base64 字符携带 6 位信息（一个字节有 8 位）。这个 6:8 的比例就是编码输出比原始输入大约大 33% 的原因 — 我们稍后会详细讨论这个话题。

当输入不是 3 的倍数时

如果最后一组不足 3 个字节，则会添加填充。编码器添加 = 字符使输出长度为 4 的倍数：

• 剩余 1 个字节 → 2 个 Base64 字符 + ==
• 剩余 2 个字节 → 3 个 Base64 字符 + =
• 3 个字节已满 → 4 个 Base64 字符，无填充

例如，"Fo"（2 字节）被编码为 Rm8=。

关于 Base64 不是什么的说明

Base64 经常与加密混淆，因为其输出看起来像乱码。只要立即解码，无需密钥就能揭示原始文本。如果您需要保护数据，请使用合适的加密算法（AES、ChaCha20 等），然后将加密后的字节用 Base64 编码以便传输。仅靠 Base64 不能提供机密性。

Base64 的常见用途

Base64 出现在 Web 上的许多日常场景中，用户往往没有意识到。

Data URI

现代浏览器允许您使用 data: URI 直接将图像、字体和其他媒体嵌入到 HTML 或 CSS 中：

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">

Base64 编码的图像数据直接存在于 HTML 文件中 — 无需单独的 HTTP 请求。这在小型图标、精灵图和 Web 字体中很常见，当额外的 HTTP 往返比内联字节更昂贵时使用。

但 Base64 Data URI 并不总是大型资源的最佳选择。33% 的大小开销意味着一个 100 KB 的图标变成了 133 KB 的内联文本，而且浏览器无法将其与 HTML 页面分开缓存。大多数网站仅对几 KB 以下的资源使用 Data URI。

JWT 和 API 令牌

JSON Web Token 使用 Base64url（URL 安全变体）对令牌的头、负载和签名段进行编码。如果您曾经检查过 JWT：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

每个用点分隔的段都是 Base64url 编码的 JSON。您可以将任何段粘贴到此工具的解码区来检查其内容。

邮件附件（MIME）

电子邮件最初设计为仅支持 7 位 ASCII。要发送二进制附件（图像、PDF、电子表格），MIME 标准将它们编码为 Base64。邮件客户端在打开消息时自动解码。

一个常令人困惑的细节：MIME Base64 传统上每 76 个字符换行。如果从邮件源码中提取 Base64 数据，它可能包含嵌入的换行符。该工具的解码器会自动处理换行符 — 您可以直接粘贴多行 MIME Base64，无需预处理。

PEM 证书和密钥

SSL/TLS 证书和私钥以 PEM 格式分发，它用 Base64 编码 DER 数据，并用头部和尾部行进行包装：

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----

PEM 本质上就是带标签包装的 Base64。您可以解码 PEM 文件的 Base64 正文来检查原始的 DER 内容，但结果将是二进制的，而不是可读文本。

HTTP 基本认证

HTTP Basic auth 头部将 用户名:密码 编码为 Base64：

Authorization: Basic YWRtaW46c2VjcmV0

字符串 YWRtaW46c2VjcmV0 是 admin:secret 的 Base64 编码。这里的 Base64 是一种序列化机制，而不是安全措施 — 任何看到头部的人都可以轻松解码凭证。

什么是 .b64 文件

.b64 文件是一种纯文本文件，其全部内容是一个 Base64 字符串。.b64 扩展名是一种命名约定，表示"此文件包含 Base64 数据" — 与任意文本、源代码或二进制格式不同。

您可能遇到 .b64 文件的情况：

• 从此类工具导出编码输出
• 以可移植文本格式存储加密密钥或证书
• 在使用基于文件的工作流的系统之间交换 Base64 数据

.b64 文件是纯文本，因此您可以在任何文本编辑器中打开它以查看其内容并将字符串复制到解码器中。该工具在编码和解码部分都接受 .b64 文件，通过拖放或文件选择方式。

工作原理

该工具使用浏览器的内置 Base64 函数，并增加了一层 UTF-8 安全处理。

核心转换

JavaScript 提供了两个原生 Base64 函数：

• btoa(input) — 将字符串转换为 Base64（二进制→ASCII）
• atob(input) — 将 Base64 转换回字符串（ASCII→二进制）

这些函数仅适用于 Latin-1（ISO-8859-1）字符。如果传入包含超出 Latin-1 范围的字符（如中文、日文或表情符号）的字符串，btoa() 将抛出 DOMException。

UTF-8 安全编码

为了正确处理所有 Unicode 文本，该工具包装了原生函数：

function encode(text, urlSafe, noPad) {
  let utf8 = encodeURIComponent(text);
  let base64 = btoa(utf8);
  if (urlSafe) base64 = base64.replace(/\+/g, '-').replace(/\//g, '_');
  if (noPad) base64 = base64.replace(/=+$/, '');
  return base64;
}

function decode(base64) {
  let restored = base64.replace(/-/g, '+').replace(/_/g, '/');
  while (restored.length % 4 !== 0) restored += '=';
  let utf8 = atob(restored);
  return decodeURIComponent(utf8);
}

encodeURIComponent 将文本转换为 UTF-8 百分号编码形式，仅包含 btoa 可以处理的 ASCII 字符。解码路径以相反顺序恢复。

要查看为什么这很重要，尝试直接用 btoa 编码表情符号"😊" — 它会抛出错误。使用 UTF-8 包装器后，它变成 J UmbKSA4bQ，并能正确解码回 😊。

处理 URL 安全输入

解码函数在将字符串传递给 atob 之前始终执行两个转换：

1. 将 - 替换为 +，将 _ 替换为 /（反转 URL 安全编码）
2. 如果字符串长度不是 4 的倍数，添加 = 填充

这意味着解码端无需切换任何设置。无论标准 Base64、URL 安全 Base64、带填充还是不带填充，解码器都能自动处理。

事件流程

当您在文本区域中输入或粘贴时，input 事件监听器触发。调度器会缓冲快速的按键（大约 16 毫秒的去抖，与一帧同步），然后运行编码或解码函数。结果会在下一个屏幕刷新时显示在输出文本区域中。

标准 Base64 与 URL 安全 Base64

编码区的两个复选框对应 Base64 的两个明确定义的变体。

标准 Base64（RFC 4648 §4）

使用完整字母表：A–Z、a–z、0–9、+、/。这是原始形式，除了 + 和 / 具有特殊含义的地方之外，在任何地方都适用。

URL 安全 Base64（RFC 4648 §5）

替换两个在 URL 中会引起问题的字符：

标准 Base64 Pz4/Pj8+QA== 在 URL 安全形式下变为 Pz4_Pj8- QA_（注意：示例中的填充 = 也已省略，但 URL 安全也可以使用填充）。

何时使用哪种

该工具的解码端会自动检测使用的变体，因此您无需更改设置即可粘贴任何格式。

常见误解

一些开发者认为 URL 安全 Base64 是一种不同的算法。其实不是 — 只是字母表变了两个字符。任何标准 Base64 解码器可以通过在处理前映射 - → + 和 _ → / 来适应它。这正是该工具在解码端所做的。

Base64 的填充

Base64 字符串末尾的 = 字符是填充 — 它们不是编码数据的一部分。

为什么存在填充

Base64 以 3 个字节为一组处理输入。如果最后一组不足 3 个字节，编码器会添加 = 作为填充，使总长度为 4 的倍数。某些解码器需要这样做，并且它允许无歧义地连接多个 Base64 字符串。

"无填充"的含义

启用"无填充"后，编码器会从输出中去除尾部的 = 字符。示例：

• 输入：Fo → Rm8=（带填充）→ Rm8（无填充）
• 输入：Foo → Rm9v（两种情况都无填充 — 正好是 3 的倍数）

许多现代系统接受无填充的 Base64，该工具的解码器始终处理它。如果输出要发送到的系统不需要或不想要填充，请启用此选项。

互操作性矩阵

该工具的解码端自动接受所有四种组合：

无需调整任何设置。解码器在处理前会规范化输入。

何时需要填充

某些系统严格要求填充，特别是：

• Data URI: data:image/png;base64,... — 浏览器解析器期望正确填充的 Base64。
• 较旧的 Base64 库: 某些实现会完全拒绝无填充的输入。

如果您不确定目标系统是否需要填充，请保持启用（默认）。只有在您同时控制编码器和解码器时，才安全地去除填充。

Base64 与其他编码方案的比较

Base64 是几种二进制到文本编码方案之一，每种方案在密度、字母表大小和用例方面有不同的权衡。

为什么 Base64 最受欢迎

Base64 对大多数实际应用来说是一个最佳平衡点。与使输入大小翻倍的 Hex 相比，Base64 的 33% 开销显著更高效。与 Base85 相比，Base64 实现更简单（每种语言都有内置解码器），其字母表避免了 Base85 中某些字符（如 " 或 \）在某些上下文中引起的引用问题。

何时使用其他方案

• Hex: 当人类可读性和调试比大小更重要时。像 4f6f 这样的 Hex 字符串可以立即被识别为编码数据。b293 作为 Base64 就不那么明显了。
• Base32: 当不需要大小写区分时（例如，在电话上朗读、印刷在产品上）。Base32 仅使用大写字母和数字。
• Base85: 当在受限通道中一个字节的开销很重要，并且您控制管道的两端时。

对于一般的 Web 编码，Base64 是正确的默认选择。该工具遵循这个约定。

性能与大小考量

Base64 简单且通用，但在处理大量数据时，实际成本很重要。

33% 的开销

每 3 个输入字节产生 4 个输出字节，比例为 4:3。实际上，包括填充和换行在内，小输入的开销约为 37%，对于足够大的输入，稳定在 33%。

Base64 与压缩

对 Base64 文本进行 Gzip（或 Brotli）压缩通常效果不佳。Base64 输出具有均匀的字符分布 — 64 个字符中的每个出现的频率大致相同 — 这消除了压缩算法赖以生存的模式。压缩的 Base64 字符串通常只比未压缩形式小 5–10%，而原始二进制数据可以达到 60–80% 的压缩率。

这意味着：

• 不要在压缩前对数据进行 Base64 编码。先压缩，如果需要再编码。
• 不要依赖传输层压缩（如 HTTP gzip）来补偿 Base64 的开销。它不会起作用。

何时不应该使用 Base64

Base64 在您需要将二进制数据塞进纯文本通道时很有用。如果通道原生支持二进制传输，则跳过 Base64：

• 文件上传: 使用 multipart/form-data 的原生二进制，而不是 JSON 中的 Base64。否则文件到达服务器时大 33%，上传时间更长。
• 数据库存储: 将二进制数据存储为 BYTEA（PostgreSQL）、BLOB（MySQL/SQLite）或 varbinary（MSSQL），而不是 Base64 文本。
• 服务间 API 调用: 使用带二进制字段的 gRPC、Thrift 或 MessagePack，而不是 Base64 编码的 JSON 字符串。

对于文本负载（JWT 负载、HTML 内容、电子邮件正文），开销可以忽略不计，Base64 的便利性值得权衡。

缓存影响

将 Base64 Data URI 嵌入到 HTML 或 CSS 中会使编码内容成为页面资源的一部分。浏览器无法独立缓存该 Data URI — 对页面的更改会使其失效。通过 <img src="icon.png"> 请求的单独图像文件可以使用 Cache-Control 头在不同页面之间缓存。对于超过几 KB 的资源，单独的文件在大多数情况下性能更好。

常见陷阱与误解

Base64 很简单，但一些反复出现的误解会导致实际错误。

Base64 不是加密

这是最常见的误解。因为 Base64 的输出看起来像随机字符，许多开发者假设它提供了一些保护。其实不是。解码不需要密钥或密钥。将 Base64 字符串视为任何人都可以读取的纯文本。

如果您看到一个服务将密码或 API 密钥存储为 Base64，请将其视为安全问题 — 数据是以明文存储的。

大小写敏感性

Base64 字母表区分大小写：

• 大写：A–Z（值 0–25）
• 小写：a–z（值 26–51）

像 R 和 r 这样的错误会完全改变解码后的值。如果解码输出看起来不对，请检查输入的大小写错误。

MIME 换行

MIME 编码的邮件附件每 76 个字符对 Base64 正文进行换行：

SGVsbG8sIHdvcmxkISBUaGlzIGlzIGEgdGVzdCBvZi BiYXNlNjQgZW5jb2Rpbmcu
VGhpcyBpcyB0aGUgc2Vjb25kIGxpbmUu

并非所有 Base64 解码器都能处理这些嵌入的换行符。该工具可以 — 您可以直接粘贴多行 MIME Base64，无需预处理。不处理换行的解码器会产生乱码结果或错误。

隐藏的空白

从电子邮件、PDF 或网页复制文本可能会带入不可见的空白字符（空格、制表符、零宽空格、不间断空格）。这些不是有效的 Base64。如果一个看起来有效的 Base64 字符串无法解码，首先将其粘贴到纯文本编辑器中检查隐藏字符，或从源重新复制。

拼接带填充的字符串

直接拼接两个带填充的 Base64 字符串不一定会正确解码。填充 = 属于每个字符串的最后一组，拼接可能会创建歧义的边界。这是故意的 — 填充防止了单个字符串的歧义。对于多部分数据，请分别处理每个部分。

如何使用

使用 Base64 编码器和解码器无需设置、注册或账户。

将文本编码为 Base64

1. 在 Base64 编码 区域，在输入文本区域中输入或粘贴文本。
2. 输出区域会自动更新为编码结果。
3. 可选地，启用 URL 安全（用于 Web 的安全变体）或 无填充（去除尾部 =）。
4. 点击 复制 将编码文本复制到剪贴板，或点击 下载 Base64 保存为 .b64 文件。

将 Base64 解码为文本

1. 在 Base64 解码 区域，将 Base64 字符串粘贴到输入区域。
2. 解码后的文本会立即出现在输出区域。
3. 如果输入不是有效的 Base64，将显示错误消息。
4. 点击 复制 或 下载 保存解码结果。

使用文件上传

• 编码区域: 将 .txt 文件拖放到上传区域以加载要编码的内容。
• 解码区域: 将 .b64 或 .txt 文件拖放以加载要解码的 Base64 内容。

文件内容被读取并放入输入文本区域，立即进行处理。

教程

场景： 您正在构建一个与 API 通信的 Web 应用程序。API 期望请求负载中的短文本字段编码为无填充的 URL 安全 Base64。您需要对文本进行编码，检查输出，并确认 API 会接受它。稍后，您将从同一 API 收到包含需要解码的 Base64 编码字段的响应。

本教程涵盖完整的往返过程。

第 1 部分：编码

1. 在浏览器中打开 Base64 编码器和解码器。您将看到两个部分：左侧是编码，右侧是解码。

2. 在编码输入区域中输入以下文本：

   你好，API 服务器。这是负载。
   

   输出区域会立即显示标准 Base64 编码。结果以 5L2g5aW9 开头。到目前为止一切顺利。

3. API 规范要求无填充的 URL 安全 Base64。同时启用 URL 安全 和 无填充 复选框。观察输出如何变化：

   • + 字符（如果有）变为 -
   • / 字符变为 _
   • 尾部的 = 字符被去除

4. 点击 复制 将编码结果复制到剪贴板。将其粘贴到您的 API 请求负载中。

第 2 部分：解码

5. API 响应一个包含 Base64 编码字段的 JSON 负载：

   {
     "status": "ok",
     "message": "eyJzdWIiOiAiMTAwMSIsICJuYW1lIjogIkFQSSBHYXRld2F5In0="
   }
   

6. 复制 message 的值并将其粘贴到 解码 输入区域。

   输出区域会立即显示解码后的文本：

   { "sub": "1001", "name": "API Gateway" }
   

7. 您现在可以读取像 JWT 这样的 JSON 负载了。如果 API 使用了 URL 安全 Base64（字符串中没有 +//，或者有 -/_），解码器会自动处理它。

第 3 部分：基于文件的工作流

8. 假设您需要将编码后的负载发送给更喜欢文件的同事。在编码区域，点击 下载 Base64。浏览器会打开"另存为"对话框，建议文件名 download.b64。保存文件。

9. 同事收到文件，打开同一个工具。他们将 download.b64 拖放到 解码 区域的上传区。文件内容出现在输入区域，解码后的文本立即显示。

这个往返过程 — 带选项编码 → 复制或下载 → 自动检测解码 — 涵盖了最常见的实际工作流。您无需考虑字符变体或填充规则，因为工具会处理所有规范化工作。

专业提示

• 同时编码和解码: 两个区域是独立的。您可以在编码区域输入文本的同时，在解码区域粘贴另一个 Base64 字符串。使用这种方法并排比较两个方向的输入和输出。

• JWT 使用 URL 安全: 处理 JWT 令牌时，始终启用 URL 安全模式。JWT 段使用 URL 安全变体（RFC 7515）。将 JWT 段粘贴到解码区域时，工具会自动检测 URL 安全字符。

• 粘贴前修剪空白: 某些 Base64 数据源包含尾随换行符或空格。解码器处理修剪后的输入效果最佳。如果看到"无效的 Base64 字符串"错误，检查粘贴的文本中是否有多余的空白。

• 长输出请下载: 对于长的 Base64 字符串，使用下载按钮而不是复制。原生的"另存为"对话框让您选择保存位置，结果保存为 .b64 或 .txt 文件，便于转发或存档。

• 上传代替输入: 如果您已有包含文本或 Base64 数据的文件，直接拖放到上传区域。这比打开文件、全选、复制、然后粘贴更快 — 尤其是大文件。

• 解码以检查格式: 收到 Base64 字符串但不确定它包含文本还是二进制数据？粘贴到解码区域。如果输出是可读文本，您就完成了。如果包含乱码或替换字符（），则原始源可能是二进制（图像、PDF 或其他非文本格式）。

替代工具

还有其他几种方法可以编码或解码 Base64，每种方法都有不同的权衡。

对于隐私、实时反馈和无需命令行知识来编码或解码 Base64 文本，此工具提供最佳用户体验。

数据隐私

Base64 编码器和解码器在您的浏览器中本地处理所有内容。您输入的文本永远不会发送到服务器、存储在数据库中或由系统记录。

所有转换都使用 JavaScript 原生的 btoa() 和 atob() 函数在浏览器内存中执行。此页面不包含分析脚本、跟踪像素或第三方嵌入。不会创建或读取 cookie、localStorage 或 sessionStorage 条目。

初始页面加载后，该工具完全离线工作。即使断开互联网连接，您也可以继续编码和解码，不会中断。您可以通过在飞行模式下使用该工具或在浏览器开发者工具中检查网络活动来验证 — 页面加载后，没有请求离开您的设备。

故障排除

技术规格

• 核心算法: btoa() / atob() 包装 encodeURIComponent / decodeURIComponent 实现 UTF-8 安全
• 标准: RFC 4648 §4（标准 Base64）、RFC 4648 §5（URL 安全 Base64）
• 输入处理: 解码时自动转换 URL 安全字符（- → +、_ → /）和填充规范化
• 实时处理: 文本区域的 input 事件监听器，去抖到约一帧（16 毫秒）
• 文件 I/O: 上传使用 FileReader API，下载使用 showSaveFilePicker（File System Access API）和 <a download> 回退
• 下载格式: .b64（编码后）、.txt（解码后）
• 上传格式: .txt（编码区域）、.b64 / .txt（解码区域）

性能基准

在 2020 年中端笔记本电脑上测量，使用 Chrome 120。性能随输入大小线性扩展。对于小于 100 KB 的典型文本负载，转换几乎是瞬时的。

浏览器兼容性

showSaveFilePicker 需要基于 Chromium 的浏览器（Chrome、Edge、Opera、Samsung Internet）。在 Firefox 和 Safari 中，下载会自动回退到 <a download> 方法。

隐私与安全

• 零数据传输：所有文本处理在浏览器内存中完成
• 不使用 Cookie、localStorage 或 sessionStorage
• 工具页面上无分析或跟踪脚本
• 初始页面加载后完全离线工作
• 无需注册、登录或 API 密钥

功能特色

• 将文本编码为 Base64，将 Base64 解码为文本（实时转换）
• URL 安全模式（使用 -_ 代替 +/，RFC 4648 §5）
• 无填充选项（去除尾部 = 号，RFC 4648 §3.2）
• 内置 Base64 编码方案和 .b64 文件格式说明
• 支持 .txt 和 .b64 文件的拖放上传
• 通过原生"另存为"对话框将结果下载为 .b64/.txt 文件
• 完全在客户端运行 — 不向服务器发送数据，离线也可使用

常见问题