Back

Base64 编码/解码器

Base64 是一种将二进制数据用 64 个 ASCII 字符表示的编码方案。它常用于在 JSON、XML 和 URL 等基于文本的格式中嵌入二进制数据。此工具可解码 Base64 以显示原始内容，并自动检测解码结果是否为 JSON、XML 或其他可解析的格式。

规范

常见用例

  • 解码 Base64 编码的 API 载荷和 Webhook
  • 检查 JWT 令牌中的编码数据
  • 解码邮件附件（MIME Base64）
  • 调试编码后的错误消息和堆栈跟踪
  • 查看环境变量中编码的配置值

功能

  • 将标准 Base64 解码为 UTF-8 文本
  • 处理 URL 安全的 Base64 变体（用 - 和 _ 替代 + 和 /）
  • 自动检测解码后的内容类型（JSON、XML 等）
  • 检测到结构化数据时可链式转到相应的解析器
  • 将文本编码为 Base64
  • 解码后的二进制图像数据支持图片预览
  • 非 UTF-8 二进制数据的十六进制查看器
  • 格式检测标签（标准 / URL 安全 / 混合）

示例

编码的 JSON

试试看 →

一个解码后为 JSON 对象的 Base64 字符串。

eyJuYW1lIjoiRGVjb2RlVGhpcyIsInZlcnNpb24iOiIxLjAuMCJ9

简单文本

试试看 →

一条 Base64 编码的问候消息（解码后为 "Hello, World!"）。

SGVsbG8sIFdvcmxkIQ==

提示

  • Base64 是编码，不是加密。它不提供任何安全性。
  • 末尾的 = 填充字符在某些实现中可以省略。
  • URL 安全的 Base64 用 - 替代 +，用 _ 替代 /，以避免 URL 编码问题。
  • Base64 会使数据大小增加约 33%。

理解 Base64 编码/解码器

Base64 是一种在 RFC 4648 中定义的二进制到文本编码方案，使用 64 个可打印的 ASCII 字符（A-Z、a-z、0-9、+、/）加上填充字符（=）来表示任意二进制数据。其主要用途是在可能无法正确处理原始字节的文本系统（如电子邮件、JSON 载荷、XML 文档和 URL 参数）中传输二进制数据。

编码过程将每三个字节（24 位）的输入分成四个 6 位组。每个 6 位值映射到 64 个字符之一。当输入长度不是三字节的倍数时，用一个或两个 = 字符填充输出，使其长度为四的倍数。这意味着 Base64 编码后的数据比原始数据大约大 33%。

存在两种主要变体。标准 Base64 使用 + 和 /，用于 MIME 邮件编码。URL 安全的 Base64（base64url）用 - 替代 +，用 _ 替代 /，以避免 URL 保留字符。JWT 令牌使用不带填充的 URL 安全变体。某些实现省略末尾的 = 填充，因为可以从编码数据推断原始数据长度。

Base64 在 Web 开发中随处可见。Data URI 在 HTML/CSS 中嵌入图片和字体。JWT 令牌由三个 Base64url 编码的段组成。SAML 消息是 Base64 编码的 XML。API 响应可能在 JSON 中将二进制内容编码为 Base64。重要的是，Base64 是编码，不是加密——它不提供任何安全性或机密性。

Base64 不是加密形式，绝不应被视为加密。它只是将数据转换为另一种表示形式，不涉及任何密钥或秘密，任何人都可以立即解码 Base64 字符串。如果敏感数据被 Base64 编码，它实际上是完全暴露的。对于需要保密的数据，请使用 AES 或 RSA 等实际的加密算法。标准 Base64 使用 + 和 / 作为第 62 和第 63 个字符，而 URL 安全的 Base64（base64url，定义在 RFC 4648 第 5 节）用 - 和 _ 替代它们，因为 + 和 / 在 URL 中有特殊含义。JWT 令牌始终使用不带填充的 URL 安全变体。

= 填充字符确保编码输出长度始终是 4 的倍数。由于 Base64 将 3 个字节编码为 4 个字符，长度不是 3 的倍数的输入需要填充：余 1 个字节产生 ==，余 2 个字节产生 =。包括 JWT 在内的某些实现完全省略填充，因为解码器可以从编码字符串长度计算出原始长度。

33% 的大小增加是编码本身固有的：每 3 个字节（24 位）变成 4 个 ASCII 字符（32 位），固定的 4/3 扩展比率无法降低。如果大小是个问题，可以在编码前压缩数据。对于大型二进制资产，应考虑使用多部分上传或二进制 WebSocket 帧等正规的二进制传输机制，而不是在文本格式中嵌入 Base64。

← 返回所有工具