免费在线 Base64 编码器与解码器

将文本转换为 Base64 或将 Base64 解码回文本。支持文件到 Base64 的转换。所有操作都在您的浏览器中运行。

您的数据永远不会离开您的设备
将文件拖放到此处 或点击浏览（最大 5 MB）

什么是 Base64？

Base64 是一种二进制到文本的编码方案，一种把任意字节序列（二进制数据）表示成一串普通 ASCII 字符的方法，这样数据能通过仅支持文本的通道传输而不被破坏。这个名字反映了字母表的大小：选了 64 个字符，专门挑那些能原样通过 7 位干净传输的字符。标准字母表是 A-Z（位置 0-25）、a-z（26-51）、0-9（52-61），然后 +（62）和 /（63）。当输入长度不是 3 的精确倍数时，字符 = 作为填充保留。每三个输入字节（24 位）变成四个输出字符（每个携带 6 位），这就是为什么 Base64 编码后的数据比原始数据 大约大 33%。

工作原理：取三个字节（24 位），重新分组为四个 6 位块，在 64 字符的字母表里查每一块。经典例子：三个 ASCII 字节 M a n（0x4D 0x61 0x6E）构成 24 位模式 01001101 01100001 01101110；重新分成 6 位块：010011 010110 000101 101110 = 十进制 19、22、5、46 = 字符 T W F u。所以 "Man" 的 Base64 编码是 "TWFu"。如果输入长度不能被 3 整除，编码器会用一个或两个 = 来填充：1 字节输入产生 2 个字符 + ==，2 字节输入产生 3 个字符 + =。

Base64 的简史

Base64 起源于 IETF 的 Privacy Enhanced Mail（PEM）项目。1987 年 2 月的 RFC 989 是第一份正式定义；1989 年 8 月的 RFC 1113 进行了修订；1993 年 2 月的 RFC 1421 完成了包含 Base64 编码的 PEM 规范。Base64 进入电子邮件主流是在 MIME（多用途互联网邮件扩展）规范采用它的时候：1996 年 11 月的 RFC 2045 把 Base64 定义为二进制邮件附件的标准编码，所以你曾经附在邮件里的每一份 PDF 或图像都是以 Base64 形式过网络的。当前的权威规范是 RFC 4648（«The Base16, Base32, and Base64 Data Encodings»），2006 年 10 月由 Simon Josefsson 发布，它取代了 RFC 3548（2003 年 7 月），把 Base16 / Base32 / Base64 家族的各种编码统一在一份文档里。RFC 4648 是任何现代 Base64 实现的对标对象。

URL 安全的 Base64，为什么换掉两个字符

标准的 Base64 字母表用 + 和 /，两者都是 URL 里的保留字符。+ 在 URL 查询字符串里通常意味着「空格」（form-encoded 约定）；/ 是路径分隔符。把标准 Base64 放进 URL，意味着对两者都要做百分号编码（percent-encoding），这进一步膨胀了字符串，也很难看。RFC 4648 §5 定义了一个 URL 安全的变体：把 + 替换为 -（连字符），把 / 替换为 _（下划线）。有时叫做 Base64URL 或 base64url。结果是一串可以直接放进 URL 而不需额外转义的字符串，正是 JWT（JSON Web Tokens）、OAuth 的 state 参数、WebAuthn 凭证 ID 以及大多数现代 Web API 所用的。某些实现还会把末尾的 = 填充也去掉，因为长度由下一个字段隐式给出。JWT 的三段点分结构（头.负载.签名）就是三段 Base64URL 编码；如果你曾手动解码过 JWT，你看到的 - 和 _ 就标志着它是 Base64URL 而不是标准 Base64。

Base-N 家族，Base16、Base32、Base58、Base85

Base64 并不是唯一的二进制到文本编码。Base16（十六进制）用 16 个字符（0-9 和 A-F），100% 大小膨胀（每个字节变 2 个十六进制字符），但极易阅读，是哈希输出、文件校验和、机器标识符的通用默认。Base32（RFC 4648，也有 Crockford 变体）用 32 个字符，并刻意排除视觉上容易混淆的 0/O、1/I/L 等组合；60% 膨胀；用于 TOTP 密钥、ULID 和 Tor 洋葱地址。Base58 是 Bitcoin 的标配：58 个字符，排除容易混淆的 0/O/I/l，加上 Base64 标准里的特殊字符 +/=。Bitcoin 地址、Solana 地址以及许多加密钱包标识使用 Base58Check（Base58 加 4 字节校验和）。Base85 / Ascii85 打包密度更高（4 字节编为 5 字符，只膨胀 25%），但用的字母表包含 URL 不安全的标点；Adobe 的 PostScript 和 PDF 格式在内部用 Base85 表示嵌入的二进制数据。通用权衡是：字母表更多意味着膨胀更小，但字符集更受限；字母表更少则传输更稳，代价是输出更大。

Base64 的常见用途

编码不是加密，一个常见的安全错误

Base64 提供 零安全。任何人都能在毫秒内完全可逆地还原，字母表是公开的，算法是平凡的，任意浏览器或一行 CLI 命令都能解码。尽管如此，「Base64 编码的敏感数据」是 MITRE CWE-261（Weak Encoding for Password）中被引用最多的例子之一，并在安全审计中反复出现：用 Base64 在客户端代码里「混淆」的 API 密钥；在数据库备份文件里用 Base64「编码」的密码；用 Base64「加密」后再提交到公共 Git 仓库的密钥。它们一律没有受到保护。如果你需要真正的机密性，请用真正的加密：对称用 AES-256-GCM，非对称用 RSA-OAEP 或 ECDH+ChaCha20-Poly1305。Base64 适合传输（把二进制转成对文本友好的形式），但永远不适合用作保护。

浏览器实现：btoa / atob 与 Unicode 陷阱

JavaScript 提供了两个 Base64 内置全局函数：btoa()（binary-to-ASCII，编码）和 atob()（ASCII-to-binary，解码）。两者都是 Netscape 早期的遗留 API，有个著名的限制：它们只能处理 Latin-1 字节字符串。调用 btoa('é') 会抛 InvalidCharacterError，因为 JavaScript 字符串 'é' 包含一个高于 U+00FF 的码点，装不进单个字节。现代的修复办法是先用 TextEncoder 编为 UTF-8 字节，再把得到的 Uint8Array 转成 Latin-1 字符串供 btoa() 使用。模板：btoa(String.fromCharCode(...new TextEncoder().encode(str)))。反向解码：new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0)))。较新的浏览器把 Uint8Array.toBase64() 和 Uint8Array.fromBase64() 作为内置方法暴露出来，但 2026 年的普及度还在铺开，跨浏览器的默认方案仍是通过 btoa/atob 走 polyfill。对文件而言，FileReader.readAsDataURL() 是最简单的路径：把文件丢进 input，reader 返回一串 data:mime/type;base64,...，里面一切都已正确编码；去掉 data: 前缀就得到纯 Base64 部分。

诚实的边界：这个工具能做什么、不能做什么

这个工具把文本或文件（最多 5 MB）编码为 Base64，并把 Base64 字符串解码回文本或可下载文件。默认使用 RFC 4648 标准字母表（含 + 与 /）；URL 安全的 Base64URL（含 - 与 _）是未来的开关功能。UTF-8 文本通过 TextEncoder 正确处理，btoa-Latin-1 陷阱已修。5 MB 上限存在的原因是 Base64 把数据膨胀 33%，且编码后的字符串完全驻留在浏览器内存里；5 MB 二进制文件会产生约 6.7 MB 的 Base64 文本再加上原始缓冲区，这在任何现代设备上都没问题。对于更大的文件，标准的替代方案是命令行 base64（macOS/Linux：base64 -i input.bin -o output.txt）、Python 的 base64 模块，或 Node.js 的 Buffer.from(data).toString('base64')。这个工具不处理：流式 Base64（对超出内存的文件按片编码）；本版本不含 URL-safe 变体（计划中）；也不处理 MIME quoted-printable 编码（RFC 2045 的另一种、用于邮件文本内容的方案）。

隐私：为什么「仅浏览器」很重要

Base64 不是加密，但你正在编码的数据常常是敏感的：你正要嵌入配置文件的 API 密钥、为传输而编码的证书、要作为 data URI 嵌进文档里的内部截图，或要给客户编码的 PDF 收据。服务器端编码器看得见你的输入。这个工具完全在你的浏览器里通过 JavaScript 运行，点 Encode 时打开 DevTools 的 Network 选项卡核对一下，或加载完页面后把它切到离线（飞行模式），工具照样可用。可以放心用来编码 API 凭证、含 PII 的截图、内部文档，或任何你不愿被复制到陌生人硬盘上的数据。

常见问题

Base64 安全吗？

不安全。Base64 是编码，不是加密。任何人都可以解码 Base64 字符串。切勿使用 Base64 保护敏感数据，请使用适当的加密（AES、RSA）来确保安全。

为什么 Base64 会使文件变大？

Base64 编码使数据大小增加约 33%。三个字节的二进制数据变成四个 Base64 字符。这种开销是能够将二进制数据作为文本传输所付出的代价。

我可以编码文件吗？

可以！将任何文件拖放到编码器上，或点击浏览。文件将被转换为 Base64 Data URI，您可以直接将其粘贴到 HTML、CSS 或 JavaScript 中。

Base64 和 Base64URL 有什么区别？

两个字符。标准 Base64（RFC 4648 §4）用 + 和 / 作为字母表的第 62 个和第 63 个字符。URL 安全的 Base64URL（RFC 4648 §5）用 - 和 _ 代替，这样编码出来的字符串可以直接放进 URL，不需要百分号编码。JWT、OAuth、WebAuthn 以及大多数现代 Web API 都用 Base64URL。本工具目前输出的是标准 Base64；URL 安全版本在未来功能清单上。手动从标准转 URL 安全：把 + 换成 -，把 / 换成 _，可选去掉末尾的 = 填充。

为什么我的 Unicode 文本在有些 Base64 工具里会失败？

因为 JavaScript 的遗留 btoa() 函数只能处理 Latin-1 字节字符串，调用 btoa('é') 会抛 InvalidCharacterError。许多老的浏览器端编码器直接用 btoa，没有 UTF-8 转换步骤，所以任何非 ASCII 输入都会出错。现代代码（也是本工具）会先用 TextEncoder 编码字符串，得到 UTF-8 字节序列，btoa 再处理就稳了。更新的内置方法 Uint8Array.toBase64() 原生处理 UTF-8，但还没在所有浏览器里成为 baseline。

我的数据会被上传吗？

不会。编码和解码完全在你的浏览器里通过 JavaScript 运行。文本和文件从不离开网络，点 Encode 时打开 DevTools 的 Network 选项卡核对一下，或加载完页面后把它切到离线（飞行模式），工具照样可用。可以放心用来编码 API 凭证、含 PII 的截图、内部配置文件，或任何你不愿被复制到陌生人硬盘上的数据。

相关工具

免费在线 JSON 格式化器和验证器

立即格式化、最小化和验证 JSON。粘贴 JSON 并获得格式化输出和错误信息。免费，无需注册，可在浏览器中运行。

免费在线密码生成器

即时生成强壮的随机密码。自定义长度，包含大写字母、小写字母、数字和符号。免费，在您的浏览器中运行。

免费在线 Lorem Ipsum 生成器

按段落、句子或单词生成 lorem ipsum 占位符文本。免费，可定制，无需注册。