> base64 编码器 | text | file <

在上方的 输入 区域键入或粘贴文本。自动编码默认开启 — 输入时 Base64 结果会立即出现在 输出 区域。也可以点击 [ENCODE] 或按 Ctrl/Cmd + Enter 手动触发编码。根据 Base64 的使用场景（JWT、OAuth、URL → 两者都开启）切换 --url-safe 或 --no-padding。所有处理在本地浏览器完成：无上传、无日志、与输入内容相关的网络请求为零。

点击输入区域下方的 [upload file] 按钮，选择最大 100 MB 的文件。编码器使用 FileReader.readAsArrayBuffer 读取文件，以 32 KB 为块通过 btoa 流式处理字节（大文件不会让浏览器崩溃），并将完整的 Base64 写入输出区域。对于更大的文件，请使用命令行编码器：base64 < input.bin > output.txt（macOS/Linux），或 PowerShell：[Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin'))。

如果需要将 Base64 格式化为 Data URI（例如 data:image/png;base64,...），请在输出前加上 MIME 类型与 ;base64,，或直接使用我们专门的 图片转 Base64 工具，可输出可直接粘贴的 PNG、JPG、GIF、WebP 与 SVG Data URI。

这三种都在 RFC 4648 中定义：

• 标准 Base64（§4） 使用字母表 A-Z a-z 0-9 + /，并以 = 填充。输出长度始终为 4 的倍数。适用于 MIME、HTTP Basic Auth 和 JSON 字符串值。

• URL 安全 Base64（§5） 将 + 替换为 -，将 / 替换为 _。当 Base64 放入 URL 路径、查询参数、文件名或 JWT 段时必需 — 否则标准的 +/ 字符会需要进行百分号编码。

• 无填充（§4 与 §5 均可，即 base64url unpadded） 去除末尾的 = 字符。长度不再是 4 的倍数，但解码器可通过对 4 取模的余数推算原始长度。JWT（RFC 7515 中的 base64url）、WebAuthn 以及部分 CBOR/COSE 实现使用此格式。

解码器必须知道预期的变体类型 — 我们的 Base64 解码器 可自动识别三种变体。

所有主流语言与运行时都内置了 Base64 编码。复制即用的代码片段：

JavaScript（浏览器）：
btoa('Hello') // SGVsbG8=
// UTF-8 版本：
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8 安全

Node.js：
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL 安全、无填充

Python：
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL 安全、无填充

PHP：base64_encode('Hello')
Ruby：Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go：base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...)（无填充）
Java：Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C#：Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust：base64::engine::general_purpose::STANDARD.encode("Hello")

Shell（macOS/Linux）：echo -n 'Hello' | base64 → SGVsbG8=。Linux 下可加 base64 -w 0 以抑制 76 列换行。

Base64 输出比输入大约 33%：每 3 个输入字节变为 4 个输出字符。精确公式：含填充为 ceil(n / 3) × 4，无填充为 ceil(n × 4 / 3)。如果还按 76 列（MIME）或 64 列（PEM）换行，还会多几个字节的开销。

示例：
• 1 KB 二进制 → 约 1.37 KB Base64
• 100 KB 图片 → 约 137 KB Data URI
• 1 MB PDF → 约 1.37 MB 的 JSON 内 Base64

不宜使用 Base64 的场景：
• 大文件传输：一张 10 MB 的图片以 Base64 嵌入 HTML 会膨胀为 13.7 MB 的解析文本，阻塞主线程，而且无法单独缓存。请改用 <img src="/assets/photo.png">。
• 性能敏感的 API：JSON 中 500 KB 的 Base64 负载解析速度比等效的二进制端点慢约 2-3 倍。
• 作为安全措施：Base64 不是 加密 — 任何人都能解码。需要保密请使用 AES-GCM 或类似算法。
• 数据库 BLOB：将原始字节存为 BLOB/BYTEA，而不是 Base64 文本，可节省 33% 存储并避免编解码往返。

JWT（RFC 7515）与 OAuth PKCE（RFC 7636）都使用 无填充的 URL 安全 Base64，常称为 base64url。在本工具中生成方式：同时勾选 --url-safe 与 --no-padding，然后编码您的文本。

程序化等价写法：
• JavaScript：btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js：Buffer.from(s).toString('base64url')
• Python：base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go：base64.RawURLEncoding.EncodeToString([]byte(s))
• Java：Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

需要 base64url 的常见 JWT 字段：由点分隔的三段（header、payload、signature）、OAuth PKCE 的 code_verifier/code_challenge、WebAuthn 挑战、Web Push 的 p256dh/auth 密钥以及 Google 的 Request.state 参数。

一个常见 bug 是使用标准 Base64（+/）发送 JWT — API 会拒绝为格式错误，因为 + 在传输过程中会被 URL 解码为空格。

可以，但有一点需要注意。本编码器生成的是 Data URI 中的 Base64 部分 — 即 ;base64, 之后的内容。要构造完整的 Data URI，请在前面添加：

data:<mime-type>;base64,<encoded-output>

常见 MIME 类型：
• data:image/png;base64,... — PNG 图片
• data:image/jpeg;base64,... — JPEG 图片
• data:image/svg+xml;base64,... — SVG（或使用 data:image/svg+xml;utf8, 不经 Base64 — 通常体积更小）
• data:application/pdf;base64,... — PDF 文件
• data:application/font-woff2;base64,... — 字体嵌入
• data:text/plain;charset=utf-8;base64,... — Base64 包裹的文本

对于图片和 SVG，图片转 Base64 工具会输出可直接粘贴的完整 Data URI，可用于 CSS 的 background-image、内联 <img src="..."> 或 <object data="..."> 标签。

体积警告：超过 20-30 KB 的 Data URI 会损害 LCP（Largest Contentful Paint），因为浏览器无法预加载 — 请让内联 Base64 图片保持较小体积，较大资源请优先使用带 loading="lazy" 的普通 <img>。

安全 — 没有任何数据离开您的浏览器。 编码完全运行在 JavaScript 中，使用原生的 btoa()、TextEncoder 与 FileReader API。没有针对输入内容的网络调用、没有遥测、没有日志、没有第三方分析。您可以在编码时打开 DevTools 的 Network 面板，观察到零相关请求。

不过，Base64 不是加密 — 它是可逆的编码，任何拿到输出的人都能解码。因此：
• 不要把生产环境密钥以编码形式粘贴到聊天、截图或日志中。
• 对于 HTTP Basic Auth，Authorization: Basic Base64 请求头仅在 TLS（HTTPS）下才安全。在明文 HTTP 上非常容易被嗅探。
• 要真正的机密性，请使用 AES-GCM、age、sops 或 KMS — 然后如需传输再对密文 Base64 编码。

对于严格的数据外泄策略，可将此页面离线保存（Cmd/Ctrl + S）。由于没有服务器依赖，加载一次后编码器即可在完全气隙环境下运行。

本编码器通过文件处理器中的硬性限制支持最大 100 MB 的文件 — 对大多数图片、PDF、ZIP 压缩包，甚至短视频都足够了。性能目标：

• < 1 MB：编码在 50 ms 内完成，UI 不冻结。
• 1 – 10 MB：根据 CPU 需要 100-500 ms。由于我们以 32 KB 为块进行编码，浏览器保持响应。
• 10 – 100 MB：2-15 秒。粘贴/滚动如此巨大的 Base64 字符串时，输出文本框可能略有延迟。如有需要，可从 DevTools 将输出下载为 .txt 文件。
• > 100 MB：被阻止 — 浏览器内存开销（输入字节 + 二进制字符串 + Base64 字符串 ≈ 文件大小的 3-4 倍）可能导致标签页崩溃。请使用：

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

对于流式/多 GB 工作流，请参阅 大文件 Base64 编码，了解 Node.js/Python 下避免一次性加载全部内容的分块方式。

本编码器使用 UTF-8，这也是现代 Web、JSON、Linux、macOS 以及几乎所有编程语言默认使用的编码。底层实现中，文本通过 new TextEncoder().encode(input) 处理，始终产生 UTF-8 字节，然后才进行 Base64 编码。

为什么这很重要：较旧的 JavaScript btoa() 函数仅支持 Latin-1，遇到 é、中 或 😀 等字符时会抛出 InvalidCharacterError。我们的封装为您完成 UTF-8 转换，因此 emoji、中文、日文、韩文、阿拉伯文、西里尔文以及任意 Unicode 码点都能正确编码。

若需其他编码：
• UTF-16 LE（Windows 原生）：较少见 — 通常意味着遗留互操作。无论如何请先使用 new TextEncoder({ fatal: true }).encode(s)，然后在上游转换。
• ISO-8859-1 / Latin-1：编码前将 0-255 码点手动映射到字节。
• GB18030、Shift_JIS、EUC-KR：先使用 Node.js 中的 iconv-lite 等库进行转码。

一个细微陷阱：如果您的源数据已经是非 UTF-8 编码（例如读取一个遗留的 MySQL dump），请先用正确的编解码器解码，再重新编码为 UTF-8，然后再 Base64 — 否则解码后的 Base64 将保留乱码（mojibake）。