Base64 是字节在只传文本的通道中传输时的写法：JSON 文件、XML 属性、邮件头、URL，以及内嵌图标的 CSS 规则，都属于这类通道。这个页面把文本编码成 Base64，也能解码回来，并处理那些容易让朴素实现悄悄出错的部分：两套字母表、可选的填充、被换行折过的长字符串，以及并非 Latin-1 的文本。
Base64 编码与解码 - Danfio
https://danfio.com/tools/base64-encoder/ - 从本页打印
文本已编码为 Base64
标准
44 字节 的文本变成了 60 个 Base64 字符。
VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4=
可以复制，也可以下载成文件。放进 JSON、XML 属性、邮件头或 data URL 的就是这种编码。
它还覆盖日常工作中与 Base64 相邻的两种包装：百分号编码，三种常见口径对空格和加号的含义并不一致；以及 `data:` URL，它就是在 Base64 前面加了一段头部。把一段 data URL 粘进来，就能在做任何处理之前先看清载荷到底是什么格式。
把字节写成文本是一种运输手段，而不是保密手段。这个页面把两件事分开处理：用标准字母表和 URL 安全字母表在文本与 Base64 之间互转，读取百分号编码，并把 `data:` URL 拆开，显示载荷的真实内容。
转换本身只是算术。三个字节变成四个字符，是因为 24 位恰好能放进四个 6 位的值，所以输出会变长三分之一，却不会有任何损失；文本先经过 UTF-8，重音字母或 emoji 才能原样往返。所有计算都在当前标签页里完成，字符串不会离开浏览器。
Base64 不是加密，也不能通过某种方式变成加密。拿到字符串的人一步就能解码，不需要密钥，也不需要任何代价。所以用这种方式写下的令牌或密码，和明文一样可读。这个页面只负责编码与解码，不提供保护。
Base64 把每三个字节写成四个字符，字符取自 64 个符号：A–Z、a–z、0–9，再加 `+` 和 `/`。三个字节是 24 位，四个字符正好容纳 24 位，因此信息一位不丢，只是输出比输入长了整整三分之一。末尾用 `=` 补齐，让总长度成为 4 的倍数，解码器才知道在哪里停下；输入长度不是 3 的倍数时，这段填充就是必需的。
它是编码，不是加密，这个区别很关键：任何人拿到 Base64 都能一步解码，既不需要密钥，也不需要额外工具。它存在的原因是有些通道只能传文本、不能传字节，而不是为了隐藏内容。用 Base64 写的密码、令牌或私钥，和明文一样可读；把秘密塞进 URL 之前，这一点尤其值得记住。
字母表正是 URL 安全变体存在的原因。`+` 和 `/` 在查询字符串与文件名里有特殊含义，所以 RFC 4648 定义了第二套字母表，把它们换成 `-` 和 `_`，并去掉填充。JWT 的各个部分用的就是这套，任何需要在链接里完整传输的 Base64 也一样。这个页面两种字母表都接受，选择只影响输出。
Base64 编码的是字节，而浏览器的 `btoa()` 拒绝 Latin-1 之外的任何字符：`btoa('café')` 会直接抛错，`atob` 则按每个字符一个字节返回，于是重音字母或 emoji 出来就是乱码。这是字符编码的问题，不是 Base64 的问题。这个页面因此先走 `TextEncoder`，解码时再走 `TextDecoder`，所以 `café`、`日本語` 和 `🎉` 都能原样往返，不会在中文、日文或表情符号上翻车。
反方向同样要小心：解码出来的字节如果不是合法 UTF-8，那它根本不是文本。解码一张 PNG 或一份 PDF 的 Base64 时就是这种情况，此时有用的回答是“这是一张图片，不是文本”，而不是满屏的替换字符。这个工具会根据开头几个字节判断它像哪种二进制格式，并把判断结果直接说出来，方便你决定下一步是换工具还是找原文件。
百分号编码是更早、也更容易让人糊涂的一层包装，因为“转义一切”并不是一条规则。编码查询字符串里的单个值时，必须转义 `&`、`=`、`#`、`/` 以及其他任何会结束该值或开启新参数的字符，这就是 `encodeURIComponent` 的行为。编码一整条 URL 时，这些分隔符必须原样保留，否则 URL 立刻失效，这就是 `encodeURI` 的行为。两者没有对错，只有用错场景。
第三种口径是表单编码，空格写成 `+` 而不是 `%20`。这正是从表单复制出来的链接粘进文档后，空格有时变成加号、加号有时又变回空格的原因。两种写法在各自语境里都正确，页面上的范围设置就是让你看清手里这份字符串究竟属于哪一种，而不是替你猜。解码时也一样：按组件规则解，`+` 仍然是 `+`；按表单规则解，`+` 才会变成空格。
示例使用页面自带的默认输入，只改设置；下面的结果与你在页面上看到的完全一致。
要做什么: 文本编码为 Base64
已编码为 Base64
标准
44 字节 的文本变成了 60 个 Base64 字符。
输入: 44 字节 · 输出: 60 字节 · 字符数: 60 · 行数: 1
The quick brown fox 会变成 60 个 Base64 字符，比原句长约三分之一。这就是把字节变成文本的代价，也是纯文本够用时不该用 Base64 的原因：JSON 里塞一段 Base64，文件大了三分之一，却没有换来任何好处。
要做什么: Base64 解码为文本 · 输入: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
已解码 Base64
文本
这段 Base64 有 36 个字符，解码后是 27 字节 的 UTF-8 文本。
输入: 36 字节 · 输出: 27 字节 · 字符数: 27 · 行数: 1
JWT 的各个部分是 Base64url：用 `-` 和 `_` 代替 `+` 和 `/`，并且不带填充。这个解码器两套字母表都接受，所以令牌片段可以直接粘进来，不必先手动补齐 `=`。
要做什么: 文本转为百分号编码（%20 风格） · 输入: a=1&b=2 · 百分号编码范围: 查询字符串里的单个值（转义 %26、%3D、%2F）
百分号编码后
已转义
按查询字符串里的一个值转义。
输入: 7 字节 · 输出: 13 字节 · 字符数: 13 · 行数: 1
在组件模式下，`&` 和 `=` 会被转义，否则它们会提前结束当前值并开启新参数。把范围切到“整条 URL”，它们就会被保留，因为在那里它们正是把 URL 串起来的结构。
不是，这一点值得说得直白：Base64 是一种可逆编码，没有密钥，任何人都能一步解回去。它的用途是让字节通过只传文本的通道，而不是隐藏内容。用 Base64 写的密码、API 令牌或私钥，和明文一样可读；甚至因为看起来更像敏感数据，反而更容易被放进本不该放的地方。
这是格式本身决定的：四个字符承载三个字节，所以输出是输入的三分之四，大约长 33%，末尾还可能多一两个填充字符。这就是全部代价。也正因如此，把大文件以 Base64 存进数据库或 JSON 载荷并不划算：多三分之一的存储、多三分之一的传输，换来的却只是一次不增加信息的转换。
因为 Base64 编码的是字节，而许多实现直接调用浏览器的 `btoa`，它拒绝 Latin-1 之外的字符，或者更糟，悄悄把它们弄坏。`café`、`日本語` 和 emoji 都会这样出问题。这里的所有文本都先经过 UTF-8，所以编码的字节就是文本真实的字节；测试也专门用重音字母、中文和 emoji 跑过往返。
只差两个字符和填充。标准字母表使用 `+` 和 `/`；URL 安全字母表（RFC 4648 §5）使用 `-` 和 `_`，通常还会去掉末尾的 `=`。这很重要，因为在表单编码里 `+` 代表空格，而 `/` 会结束路径段，标准 Base64 放进链接后可能到达时已经损坏。JWT 片段，以及大多数要在 URL 或文件名里传输的内容，都用 URL 安全形式。这个工具两种都读，写出哪一种由你选择。
因为它们确实不是：你解码的是一张图片、一份 PDF、一个 zip 或其他二进制内容的 Base64，这些字节不是合法 UTF-8。与其显示满屏替换字符，这个工具会直接说明，并根据文件签名指出格式。它还会告诉你什么做法真正有用：改粘完整的 `data:` URL，或者用本站的文件工具把文件还原出来。
data URL 就是写进文本里的文件：一个媒体类型、可选的 `base64` 标记，然后是载荷。它们常出现在 CSS 的小图标、HTML 的内联图片和 JSON API 的文档字段里。粘到这里是安全的，因为内容不会被发送到任何地方；而且有用，因为这个页面会读取头部和开头几个字节，告诉你载荷到底是什么。面对一长串以 `data:image/png;base64,` 开头的四万字符字符串时，这通常正是你想问的问题。
因为这段字符串经过的是表单编码，而不是 URL 编码。在 `application/x-www-form-urlencoded` 数据里，空格写成 `+`，所以按这套约定解码的程序会把看到的每个 `+` 都变成空格，包括标准 Base64 里的 `+`。解决办法要么一开始就用 URL 安全字母表，要么在把 Base64 放进表单之前先做百分号编码。这个页面上的百分号编码范围设置，展示的就是同一个区别。
这个页面不行：它接受粘贴或键入的文本。`.b64` 或 `.txt` 文件可以先打开再复制；如果你拿到的是 JSON API 响应里的一段 Base64 图片，粘到这里通常正是弄清它是什么的最快方式。本站的文件工具才负责把字节还原成可下载的文件。
最近复核于 2026-09-16.
本页在您的浏览器本地运行，请保留原文件备份；不涉及财务建议。 阅读完整免责声明。
Danfio 中文在线工具