Base64 在线解码与编码过程实时解析

在线 Base64 编码与解码

本工具支持在浏览器中实时进行 Base64 编码与解码：在输入框粘贴文本或 Base64 字符串，切换编码/解码模式即可查看结果，并可对照下方可视化过程理解每一步。处理在本地完成，适合调试 API、Data URI 与配置文件中的 Base64 字段。

快速解码：切换到解码模式 → 粘贴 Base64 字符串（如 aGVsbG8sIHdvcmxk）→ 复制输出区的明文。

快速编码：切换到编码模式 → 输入中文或二进制对应的文本 → 复制 Base64 结果。

规范依据 RFC 4648；浏览器端也可参考 MDN: btoa() / atob()。

Base64 是什么？

Base64 是用 64 个可打印字符表示二进制数据的编码方式，属于常见的 binary-to-text 编码。在前端实践中，常将小型图片转为 Base64 Data URI 以减少 HTTP 请求。

字符集为 0-9、A-Z、a-z 及 +、/。在 URL 中使用时，/ 易与路径冲突，因此 URL Safe Base64 将 + 换为 -，/ 换为 _（JWT 即采用此变体）。

编码时每 3×8 bit 字节变为 4×6 bit 单元，故编码后体积约增大 1/3。详见下方「原理」文档中的填充规则说明。

10101101, 10111010, 01110110
00101011, 00011011, 00101011, 00110110

常见场景

• Base64 解码：还原接口返回或日志中的编码字段
• Data URI：在 HTML/CSS 中内联小图标
• JWT：Header 与 Payload 使用 Base64URL（本工具可辅助理解编解码，JWT 完整调试见 JWT 解码器）

常见问题（精选）

Base64 是加密算法吗？

不是。Base64 是可逆的编码方式，用于在文本协议中传输二进制数据，不提供保密性（见 RFC 4648）。

Base64 解码乱码怎么办？

常见原因是未按 UTF-8 解码多字节文本，或误用了 URL Safe 字母表。本工具解码时已按 UTF-8 处理。

在线 Base64 解码是否安全？

编解码在浏览器本地完成，内容不会上传；敏感数据仍请注意使用环境与他人可见性。

转化过程

1. 将数据转化为 uint8 二进制
2. 将转化后的二进制每六个分为一组，共有 64 中可能 (0-63)
3. 将六位一组的二进制，计算出 Index (0-63)，并根据以上速对表及 Index 找到对应的 base64 字符
4. 由此编码后 base64 长度为 4 的倍数，不足使用 = 进行填充

PS: 关于第4点，使用 = 进行补充，规范描述: base64 将原数据三个字节数最终编码为四个字节，但是原数据字节数最终有可能不足三个，原数据字节数可能会多一到两个字节。如果多一个字节，则编码结果最后填充 ==，如果多两个字节，则编码结果最后填充 =。

见: https://datatracker.ietf.org/doc/html/rfc4648#section-4

1. The final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding.
2. The final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters.
3. The final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.

规范以原字节数为视角进行描述，如果原数据字节数为 1，编码结果长度为2，需填充 2 个 =，原数据字节数为 2，编码结果长度为 3，需填充 1 个 =。换算成编码后视角而言，则为编码输出最终必须为 4 的倍数，不足使用 = 进行补齐。

API

Rest API

本站点对 Base64 提供对外 API 接口可供调用:

# 编码
$ curl -L devtool.tech/api/base64?s=hello

# 解码
$ curl -L devtool.tech/api/base64?s=5bGx5pyI&d

Live Demo

JS

在浏览器环境中可借助 btoa/atob 编码解码，在 Node 环境中借助于 Buffer API 编码解码。另可借助于 base64-js

const base64 = {
  encode (v: string) {
    return isBrowser ? btoa(v) : Buffer.from(v).toString('base64')
  },
  decode (v: string) {
    return isBrowser ? atob(v) : Buffer.from(v, 'base64').toString()
  }
}

Bash

在 Mac/Linux 中可以通过命令行工具 base64 进行解码编码

# 编码
$ echo hello | base64
aGVsbG8K

# 解码
$ echo aGVsbG8K | base64 -d
hello

常见问题

Q: 如何在线 Base64 解码？

切换到解码模式，在输入框粘贴 Base64 字符串（可含 = 填充），输出区即显示 UTF-8 明文。处理在浏览器本地完成，规范依据 RFC 4648。

Q: Base64 编码后数据会变大多少？

Base64 编码会将每 3 个字节的原始数据转换为 4 个字符，因此编码后的数据量大约增大 1/3（约 33%）。如果原始数据长度不是 3 的倍数，还会用 = 号填充到 4 的倍数。此外，在某些场景下（如 MIME 邮件）还会插入换行符，进一步略微增加数据量。

Q: Base64 是加密算法吗？

Base64 不是加密算法，而是一种编码方式。它的目的是将二进制数据转换为可打印的 ASCII 文本，以便在只支持文本的协议（如电子邮件、JSON）中安全传输。Base64 编码是完全可逆的，任何人都可以直接解码还原原始数据，不涉及密钥或安全性保障。如果需要保护数据机密性，应使用 AES 等加密算法。

Q: URL Safe Base64 和标准 Base64 有什么区别？

标准 Base64 使用 + 和 / 作为第 62、63 个编码字符，但这两个字符在 URL 中有特殊含义（+ 会被解析为空格，/ 是路径分隔符）。URL Safe Base64 将 + 替换为 -，将 / 替换为 _，从而可以安全地嵌入 URL 和文件名中。在实际使用中，JWT（JSON Web Token）就采用了 URL Safe Base64 编码方式。

Q: 为什么图片要转成 Base64？

将小图片转换为 Base64 格式嵌入 HTML 或 CSS 中，可以减少 HTTP 请求次数，从而提升页面加载速度。这种做法对于小图标、装饰性图片等尺寸较小的资源特别有效。但对于较大的图片，Base64 编码后体积增大约 1/3，反而会增加 HTML/CSS 文件大小，通常建议仅对几 KB 以内的小图使用此方案。

Q: Base64 编码后的 = 号是什么意思？

Base64 编码以 3 个字节为一组进行处理，当原始数据长度不是 3 的整数倍时，需要用 = 号进行末尾填充。如果原始数据剩余 1 个字节，编码结果末尾会添加 ==；剩余 2 个字节时，末尾添加 =。= 号本身不携带数据信息，仅用于标识填充，在解码时会被忽略。

Q: Base64 解码乱码怎么办？

常见原因是把 UTF-8 多字节文本（如中文）直接交给仅支持 Latin1 的 atob() 解码。应先将 Base64 解码为字节，再按 UTF-8 解释字符串。本工具在解码时已按 UTF-8 处理。若仍乱码，请检查原始数据是否为 URL Safe 变体、是否缺少填充、或是否误用了十六进制等其他编码。

Q: 中文如何进行 Base64 编解码？

先将中文按 UTF-8 编码为字节序列，再对字节做 Base64 编码。解码时反向操作。本工具编码/解码模式均支持中文文本，无需手动转换。

Q: 在线 Base64 解码是否安全？

本工具在浏览器本地编解码，输入内容不会上传到服务器。但若粘贴的是生产环境密钥、Token 或个人数据，仍应注意周围环境与他人可见性；敏感数据建议在离线环境处理。

Q: Base64 与 URL 编码有什么区别？

Base64 将任意二进制映射为 64 个可打印字符，体积约增 33%，见 RFC 4648。URL 编码（百分号编码）仅转义 URL 中的非安全字符为 %XX，见 RFC 3986。二者用途不同，不可互换。

标准 Base64 与 URL Safe Base64

填充规则

编码以 3 字节为一组，输出 4 个字符：

1. 输入为 3 字节的整数倍：输出 4 的倍数字符，无 =
2. 余 1 字节：输出 2 字符 + ==
3. 余 2 字节：输出 3 字符 + =

RFC 4648 第 4 节 从原始字节角度描述；从编码结果看，长度必须为 4 的倍数，不足用 = 补齐。

与 URL 编码、十六进制的区别

• URL 编码（Percent-encoding）：保留 ASCII 可打印字符，非安全字符变为 %XX，见 RFC 3986
• 十六进制：每字节 2 个 hex 字符，体积为原始的 2 倍，无字母表映射
• Base64：每 3 字节 → 4 字符，体积约增 33%，适合二进制块文本化

中文与 UTF-8

JavaScript btoa() 仅接受 Latin1 字符串；中文等 Unicode 文本需先按 UTF-8 转为字节再编码。本工具在编码时处理 UTF-8 字节序列，解码时按 UTF-8 还原，避免出现「乱码」。详见 FAQ「中文如何编解码」。

参考资料

• RFC 4648 — Base64
• MDN: Base64