Base64 是一种用 64 个可打印字符来表示任意二进制数据的编码方式，它只是「换种写法」，并不是加密。这 64 个字符是 A–Z、a–z、0–9、+ 和 /，末尾不够时用 = 补位。因为这些字符在 HTTP 请求头、JSON、XML、邮件正文和 URL 里都能原样传输，所以图片、二进制内容经常会被转成 Base64 再传。
为什么是 64 个字符？因为 64 = 2⁶，每个字符正好对应 6 位数据。编码时每读取 3 个字节（24 位），就拆成 4 组 6 位，每组映射成一个字符：
Man → TWFu — 之后你遇到的 Base64 字符串，不管是 JWT 里的还是 data URI 里的，原理都和这个例子一样。
= 补齐到 4 的倍数。dXNlcjpwYXNz 的人一秒就能读出原文。千万别把密码或 API 密钥「Base64 一下」就当成安全了。很少有人主动去用 Base64，通常是在接口返回、请求头或配置文件里碰上了才需要解码。下面是几种最常见的情况：你看到的是什么、在这里怎么操作、最后能得到什么。
HTML、CSS 或打包产物里形如 data:image/png;base64,iVBORw0KGgo… 的内容。
复制 base64, 后面的部分，粘贴到这里，点解码并格式化。
SVG、JSON、CSV 这类文本内容会还原成可读文本。PNG 等二进制文件解出来会是乱码，原因见下面的常见问题排查：这里解码的结果是文本，不是文件。
形如 eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.sig 的字符串，由两个点分成三段，前两段都以 eyJ 开头，这正是 {" 编码后的样子。
复制中间那一段（两个点之间），粘贴后点解码并格式化；想一次看完整个 Token，可以直接用 JWT 解析工具。
payload 会以格式化好的 JSON 在新标签页中打开，可以随时切换树形或表格视图。URL-safe 的 - 和 _ 会自动处理。
抓包或代理日志里的 Authorization: Basic dXNlcjpwYXNz。
只复制 Basic 后面那串，粘贴后点解码并格式化。
明文的账号密码，这里就是 user:pass。这也说明 Basic 认证必须搭配 HTTPS 才算安全。
查看邮件源码或 .eml 文件时，Content-Transfer-Encoding: base64 下面那一大段按行折断的字符。
先把多行拼成一行（中间的换行不属于 Base64 字符），再粘贴并点解码并格式化。
邮件正文的文本内容。二进制附件解出来是乱码，和上面的 PNG 情况一样。
接口返回里有 "payload": "eyJ1c2VySWQiOjQyfQ==" 这样的字段，说明后端把数据编码后塞进了文本字段。
复制这个值，粘贴到这里，点解码并格式化。
解码结果会格式化成 JSON，在新标签页里打开，原始内容仍保留在编辑器中，方便并排对比。
两个方向各一个按钮，不用任何设置。全部在浏览器里完成，不上传，也不记录。
+ 和 /），并带有正确的 = 补位。= 补位也无所谓。单框式编码网站一次只能让你处理一个字符串。这一页维护的是整个会话：
每次解码都会打开一个编号标签页——Base64 #1、Base64 #2……而不是覆盖你已有的工作。你的原始 Base64 保存在根编辑器中：标签栏末尾的 + 按钮可返回那里，切换标签页会保留每一页的内容。悬停后点 ✕ 关闭标签页；关闭最后一个标签页即回到编码器。
悬停任意标签页点击它的 ⇄ 图标，再点击第二个标签页的 ⇄ 图标。提示条会确认所选内容，随后两份内容带着各自的标签名并排打开在JSON 对比页面上——非常适合排查两个本应相同的解码结果为何不同。
当解码产出 JSON 时，工具栏会切换为完整的格式化套件：Code / Tree / Table 视图、搜索、Format、Minify、Anonymize、Escape/Unescape，外加 Copy、Paste、Upload 和 Download。非 JSON 的解码结果保持纯文本。
九成的"我的 Base64 解不开"问题都落在以下五类里：
| 症状 | 原因 | 解决 |
|---|---|---|
| 被拒绝，提示“Content is not a valid Base64 string.” | 校验器发现了字母表之外的字符——通常是随字符串一起复制进来的空格、换行或引号——或者去掉填充后长度仍余出一个无法成组的字符。 | 重新精确复制字符串（去掉两侧引号），拼接折断的行，并检查两端是否有截断。 |
| 在本工具能用，换个地方却失败（或反过来） | 缺少 = 填充。许多解码器要求长度为 4 的倍数；本页会自动补齐，严格的工具不会。 | 先补 = 直到长度能被 4 整除，再交给更严格的解码器。 |
| 某个 JWT 段在别处解码失败 | JWT 使用 base64url：+ 变成 -，/ 变成 _，而且常常完全没有填充。 | 在这里是自动的——两种字母表都被接受并归一化。在别处，先把 -/_ 替换回 +// 并补齐填充。 |
解码输出是 �PNG 这类乱码 | 负载是真正的二进制（图片、zip、字体）。解码得到的字节是正确的；把它们当作 UTF-8 文本渲染就会产生替换字符。 | 数据没有损坏——只是字节没法按文本显示。二进制请使用面向文件的工具，或通过 data URI 提供。 |
| 邮件风格的 Base64 无法通过校验 | MIME 按 76 列折行输出。这里只会修剪首尾空白；字符串内部的换行属于非法字符。 | 把各行拼成一个字符串（用查找替换删除换行即可），然后重新解码。 |
| “它经过 Base64 编码了，所以我的 API 密钥藏住了，对吧？” | 不对。编码不提供任何保密性——包括本页在内的任何解码器都能瞬间还原。 | 用服务端的加密或哈希来保护秘密，彻底不要把它们放进客户端代码，并轮换任何已经以 Base64 形式外泄过的密钥。 |
离开本页后的同样操作——相同输入给出相同输出：
| 命令 / 语法 | 作用 |
|---|---|
| btoa('Man') // 'TWFu' | 浏览器 JS 编码。仅支持 Latin-1——遇到 emoji 或任何高于 U+00FF 的字符会抛错。 |
| atob('TWFu') // 'Man' | 浏览器 JS 解码。 |
| btoa(String.fromCharCode(...new TextEncoder().encode(s))) | Unicode 安全的编码技巧——与本工具内部做法一致，大输入时分块处理。 |
| echo -n 'Man' | base64 # TWFu | 命令行编码。-n 用于去掉 echo 自带的换行——否则你编码的是 Man\n，得到 TWFuCg==。 |
| echo 'TWFu' | base64 -d # Man | 命令行解码（GNU coreutils）。macOS 用 --decode 或 -D；GNU 还提供 -w 0 来禁用 76 列折行。 |
| data:[mediatype][;base64],DATA | data URI 的结构——例如 data:text/plain;base64,SGVsbG8=。逗号之后全是纯 Base64。 |
| header.payload.signature | JWT 的结构：三个 base64url 段。头部和载荷可解码为 JSON；签名解码为原始字节，本就不应可读。 |
不会。编码、解码、校验和格式化全部由浏览器里的 JavaScript 完成，没有任何网络请求。页面加载好之后，断网也能继续使用。
可以。- 和 _ 会自动转换，缺少 = 补位也没关系。但要注意，带点的完整 Token 本身不是合法的 Base64，需要分段解码，或者直接用 JWT 解析工具。
不是。输出始终是标准格式（+、/、=）。如果对方系统要求 URL-safe，请手动把 + 换成 -，/ 换成 _，再去掉末尾的 =。
这是有意设计的。原始字符串保留在根编辑器里，每次解码结果各占一个编号标签页，这样可以连续解码多段数据逐个检查，还能把任意两个结果送去对比，不用重新粘贴。
没有人为限制，取决于浏览器的内存。电脑上几 MB 的字符串很轻松。编码时做了分块处理，不会像直接调用 btoa 那样因为数据太大而报错。
免费，不用注册，没有次数限制，也没有水印。和本站其他工具一样，所有处理都在你自己的设备上完成，数据不会被发送或保存到服务器。
在处理 Token？JWT 解析工具可以一次看完 header、payload 并校验签名，和这里按段解码是很好的搭配。解码出来的 JSON 想继续整理，用 JSON 格式化工具；想对比两份解码结果，用 JSON 对比，从标签页对比过去即可。
粘贴文本或 Base64 字符串，一键编码或解码；解出来是 JSON 就自动格式化，还能多开标签页并排对比。所有操作都在浏览器里完成，数据不会上传。