About
当前语言: 中文 切换为英文

Base64 编码 / 解码

将文本编码为 Base64,或将 Base64 解码回文本。UTF-8 兼容,支持 ASCII 以外的字符。

  1. 将文本或 Base64 字符串粘贴到输入框中。
  2. 点击「编码」将文本转为 Base64,或点击「解码」将 Base64 转回文本。
  3. 如果结果要放进 URL 或 JWT,请勾选「URL 安全」—— 会使用 - 和 _,并省略填充。
  4. 点击「复制」把结果放到剪贴板。
它能做什么?

Base64 将任意字节编码为 64 个可打印 ASCII 字符,使得二进制不安全的传输通道(JSON 字符串、URL、邮件正文、环境变量、HTTP Basic 认证)可以无损传递数据。本工具正确处理 UTF-8 输入 —— 先把字符串编码为 UTF-8 字节,再对这些字节进行 Base64 编码,因此非 ASCII 字符可以完整往返。输出大约比输入大 33%(每 3 字节变成 4 字符)。

示例

对文本 "Hello, world!" 进行编码:

SGVsbG8sIHdvcmxkIQ==

对同一文本启用「URL 安全」(去掉填充)后编码:

SGVsbG8sIHdvcmxkIQ

对包含表情符号的 "café ☕" 进行编码:

Y2Fmw6kg4piV

为什么我的 Base64 字符串无法解码?

  • 标准与 URL 安全混用。 包含 - 或 _ 的字符串是 base64url,不是标准 Base64。切换「URL 安全」复选框以匹配。
  • 缺少填充。 标准 Base64 字符串长度必须是 4 的倍数。SGVsbG8 会失败;SGVsbG8= 可以。用 = 补到长度能被 4 整除。
  • 值中间夹杂空白或换行。 有些系统会在 76 字符处用 \n 换行。大多数解码器能容忍,严格实现不会。解码前先去除空白。
  • 不小心解码了两次。 解码 U0dWc2JHOA== 会得到 SGVsbG8,而它本身又是一个 Base64 字符串。如果输出看起来还像 Base64,再解码一次。
  • 非 UTF-8 的二进制数据。 如果解码出的字节不是有效的 UTF-8(例如 PNG 文件头),按文本解码会失败或显示乱码。请使用支持文件的 Base64 工具处理二进制。
  • 智能引号或可见省略号。 从字处理软件复制时,可能把 " 替换成弯引号,或用省略号截断长字符串。先经纯文本编辑器粘贴一次。
常见问题

标准 Base64 和 URL 安全 Base64 有什么区别?

标准 Base64(RFC 4648)使用 + 和 /,并用 = 补齐。URL 安全 Base64(base64url)把 + 替换为 -,把 / 替换为 _,通常省略填充,使字符串能原样放入 URL 路径或查询参数。JWT 使用 base64url。当输出要进入 URL 时,请勾选「URL 安全」。

这个工具能正确处理表情符号和非 ASCII 文本吗?

可以。输入先被编码为 UTF-8 字节,然后再 Base64 编码;解码时步骤相反。所以粘贴 "café" 再解码结果还是 "café",不会出现乱码。许多旧的 Base64 工具默认使用 Latin-1,会损坏 ASCII 之外的字符。

可以编码图片或 PDF 这样的二进制文件吗?

本页面只编码文本。要对文件进行 Base64 编码,请使用能以二进制读取文件的工具(或在浏览器控制台使用 FileReader.readAsDataURL)。本工具适用于字符串编码 —— 常见场景是嵌入凭据、配置或 JSON 字段。

为什么解码结果看起来像乱码?

通常是输入本来就不是 Base64,或者把 URL 安全 Base64 当成标准 Base64 来解(或反过来)。先切换「URL 安全」复选框试试。另一种常见原因是解码的字符串实际上是 Base64 编码的二进制而非文本 —— 那些字节不是有效的 UTF-8。

= 填充重要吗?

标准 Base64 会用 = 补齐使输出长度是 4 的倍数。多数解码器可以接受没有填充的输入,部分严格实现会拒绝。URL 安全 Base64 通常省略填充。如果解码器报错,加 = 直到长度能被 4 整除,或者把所有 = 都去掉再试。

你们会保存我编码或解码的文本吗?

不会。我们不保存你粘贴的任何文本。关闭或刷新页面时输入就消失了 —— 没有保留,我们这边也没有任何关于你编码/解码内容的记录。如需额外确认,可以在浏览器开发者工具中查看。