HandyTools Hub

Base64 编解码器

将文本编码为 Base64 或将 Base64 解码为文本。支持 UTF-8。

用一次真实转换试试

编码文本，而不是密码

待编码文本

hello

Base64 结果

aGVsbG8=

Base64 不是加密

任何人都可以解码 Base64，请不要用它保护密码、令牌或密钥。

阅读 Base64 原理指南

这个 Base64 编码/解码器可以在文本与 Base64 之间双向转换，并完整支持国际字符的 UTF-8 编码。粘贴一个值就能立刻读出结果——它也能处理 JWT 使用的 Base64url 变体，以及混进复制内容里的空白字符。适合需要在 URL 或 HTML 中嵌入数据的开发者、调试 API 负载的人、解码 Basic Auth 请求头的人，以及任何见到神秘的 aGVsbG8= 字符串想弄清里面是什么的人。

使用方法

  1. 输入文本或 Base64 字符串。粘贴多行内容也没问题——多余的换行和空格会自动处理。
  2. 选择方向：****编码把可读文本转成 Base64，解码把 Base64 还原为文本。非法输入会给出明确的错误提示，而不是静默失败。
  3. 查看输出。 转换是即时的，因此你可以在不按任何按钮的情况下修改输入并观察结果更新。
  4. 复制结果到剪贴板，一键完成，可直接用于请求头值、data URI 或配置文件。

实操示例

例 1——教科书案例。 对字符串 Man 编码得到 TWFu。M、a、n 三个 ASCII 字节分别是 77、97、110；把它们按二进制拼接得到 24 位，再切成四个 6 位值（19、22、5、46），对应 Base64 字母表中的 T、W、F、u。因为长度能被 3 整除，所以不需要填充。

例 2——填充的实际效果。 单独编码 M 得到 TQ==，编码 Ma 得到 TWE=。多出的一个字节变成两个字符加 ==，多出两个字节变成三个字符加 =。等号不携带任何数据——它们只是告诉解码器最后一组是短的。

例 3——解码一个令牌。 JWT 的中间段看起来像 eyJzdWIiOiIxMjM0NSJ9。把它粘进解码器会返回 {"sub":"12345"}——这证明 JWT 的负载只是 Base64url 编码的 JSON，任何持有该令牌的人都能读出来，它并没有被加密。

Base64 的工作原理

许多传输系统是为文本设计的：早期的 SMTP 只能保证 7 位 ASCII，而 JSON、XML 和 URL 等格式又保留了一些不能原样出现的字符。把任意二进制推过这些通道，数据就会被破坏或截断。Base64 用 64 个可打印字符来表示二进制数据，从而绕开这个问题。

编码以 3 个字节（24 位） 为一组处理输入，并把每组切成 四个 6 位值。6 位可以表达 0–63，正好是字母表的大小：A–Z（0–25）、a–z（26–51）、0–9（52–61）、+（62）和 /（63）。当输入不能被 3 整除时，用一个或两个 = 填充最后一组，让输出长度保持为四的倍数。

代价是固定的 33% 体积增长，因为 3 个字节变成了 4 个字符。这也是把大照片内联成 data URI 不划算的原因：文件大三分之一，而且浏览器必须先下载完整个文档才能解码和渲染。

URL 安全变体

标准 Base64 使用 + 和 /，而这两个字符在 URL 中都有特殊含义（+ 在查询字符串里会被解码成空格）。因此 RFC 4648 定义了 Base64url：- 取代 +，_ 取代 /，末尾的 = 通常省略。JSON Web Token、许多 OAuth 流程，以及携带二进制数据的 URL 参数都用它。如果一个字符串解码失败且含有 - 或 _，请先把它转回标准 Base64。

常见错误与边界情况

  • 把 Base64 当作加密。 它是一种表示方式，不是保护措施。没有密钥，任何人都能在毫秒内解码。把密码或 API key 存成 Base64 瞒不过任何人。
  • 重复编码。 对已经编码的字符串再编码，会让 %20 之类的痕迹膨胀，并让下一个系统无法解码。只在真正需要的边界上编码一次。
  • 以为它能缩短数据。 它总是让负载增大约三分之一。体积重要时请使用压缩。
  • 忘记 data URI 前缀。 单独的 Base64 在 HTML 里不是可用的图片；你需要在前面加上 data:image/png;base64,。图片转 Base64 工具会替你拼好它。
  • 混用变体。 含 -/_ 的字符串无法在严格的标准解码器中解码，而含 +// 的字符串会破坏 URL 安全解析器。要清楚你的消费方期望哪种变体。
  • 换行折行。 有些格式把 Base64 按 76 字符折行（MIME），另一些则要求字符串不断行。这里的解码器会忽略空白，所以两种输入都能处理——但你输出的消费方未必这么宽容。

功能特性

  • 文本与 Base64 双向转换，带严格校验
  • 完整 UTF-8 支持，包括中文、emoji 和其他多字节内容
  • 处理 Base64url 字符串，自动忽略多余的空白
  • 即时、客户端本地转换，一键复制
  • 可离线使用——没有服务器、不记录日志、不作存储

使用场景

  • Data URL： 把小图标直接内联进 HTML 和 CSS。
  • Basic Auth： 在 HTTPS 之上为 API 测试构造 Authorization: Basic 请求头。
  • API 调试： 解开 JWT、Webhook 和消息队列中的负载。
  • 纯文本通道： 让二进制或含特殊字符的数据安全穿过电子邮件、JSON 或日志。

相关工具

常见问题

为什么我的 Base64 字符串里是 - 和 _ 而不是 + 和 /？

你看到的是 Base64url，RFC 4648 定义的 URL 安全变体。它把 + 换成 -、把 / 换成 _，并且通常去掉末尾的 = 填充，这样字符串可以放进 URL 或文件名而无需百分号编码。JSON Web Token 用的就是它。要用标准解码器解开 Base64url，先把 - 换回 +、_ 换回 /，再把填充补到四的倍数。

可以对文件而不只是文本做 Base64 编码吗？

本工具只处理文本。图片请使用图片转 Base64 工具，它会读取二进制文件、应用同样的编码，并返回带正确 MIME 类型的完整 data URI。底层数学完全一样——3 个字节变 4 个字符——但文件需要一个 MIME 前缀才能在 HTML 或 CSS 里发挥作用。

Base64 会压缩或缩短数据吗？

不会，它恰恰相反：编码后的输出总比输入大约 33%。Base64 是用体积换取安全传输。如果你的目标是更小的负载，请使用压缩（gzip 或 Brotli）或更紧凑的格式，而不是 Base64。

解码时报错是什么原因？

输入包含 Base64 字母表之外的字符、长度不是四的倍数（考虑填充之后），或者其实是带 - 和 _ 的 Base64url 字符串时，解码就会失败。空白和多余换行会被自动忽略，所以常见的元凶是复制粘贴时少了或多了字符。

用 Base64 做 Basic Auth 安全吗？

只有在 HTTPS 之上才安全。Authorization: Basic 头把用户名:密码做 Base64 编码，而这是可以轻易逆转的——任何截获它的人都能立刻读到凭据。Base64 不提供任何安全性，真正保护请求的是 TLS 层。绝不要在明文 HTTP 上发送 Basic Auth。

最大支持多大的输入？

工具可以轻松处理大约 1 MB 以内的输入，足以覆盖常见的 API 负载、令牌和配置片段。对于非常大的文件，在浏览器里编码会变得又慢又占内存，应该改用带流式编码器的脚本来处理。

由 HandyTools Hub 团队审校 · 最后更新