Base64 可以解密吗？
Base64 没有「加密」，自然也谈不上「解密」，准确的说法是解码，而且一定能解开——把上面切到解码模式，粘进去点一下就是原文。它和 MD5、SHA-256 那种单向散列完全不同：后者不可逆，Base64 是完全可逆的双向编码。如果你看到有人用 Base64 来「加密」敏感数据，那是个安全问题，不是加密方案。
data:image/png;base64,... 这类整段 data URI，会自动识别并剥掉前缀。解出来是图片会直接预览，是二进制会给下载按钮。全部在浏览器本地完成，不上传任何数据。data: URI，前缀会自动剥掉；换行、空格也会自动忽略。-_）和缺失的 = 补位，不用手工修。不算，而且这是最要紧的一条。Base64 是编码：把任意二进制数据用 64 个可打印字符（A-Z a-z 0-9 + /）重新表达一遍，没有密钥、没有秘密，规则是公开的，任何人拿到都能一步还原。它解决的是「这条通道只能传文本，我要塞一张图片进去」的问题，不是「我要让别人看不懂」的问题。所以把密码、身份证号、接口密钥 Base64 一下再存进数据库或写进前端代码，等于没做任何保护——真正要不可逆请看 SHA-256 在线加密，要存密码请用 bcrypt 这类慢哈希。
这类链接长得像 data:text/html;charset=utf-8;base64,PGh0bWw+...，常见于 QQ 邮箱、部分论坛的「分享」功能。打不开不是链接坏了：Chrome 从 2017 年起禁止在地址栏直接打开顶层 data: 链接，Firefox、Edge 随后跟进，因为这个特性被大量用于钓鱼——伪造的登录页可以整个塞进一条链接里，且地址栏显示不出真实域名。
内容本身还在链接里。把整段链接（连 data:text/html;charset=utf-8;base64, 这段前缀一起）粘进上面的解码框，本页会自动识别前缀、剥掉、再解出原文。如果解出来是 HTML，你会看到完整的网页源码。看之前先有个心理准备：如果这条链接是陌生人发来的，它有相当概率是钓鱼页，解出来看看内容可以，别照着里面的表单填账号密码。
主要是内嵌：把小图标直接写进 CSS 的 background-image: url(data:image/png;base64,...) 或 HTML 的 <img src>，省掉一次 HTTP 请求；也用于把图片塞进 JSON、Markdown 或邮件正文这类只能放文本的地方。代价是体积会涨约 1/3（每 3 字节变 4 字符），而且内嵌的图片没法被浏览器单独缓存——改一个字节整个 CSS 文件的缓存就失效了。所以只适合几 KB 的小图标，照片和大图老老实实走 URL。上面勾选「加上 data URI 前缀」就能直接得到可以粘进代码的完整字符串。
那是 URL 安全变体（RFC 4648 §5）。标准字母表里的 + 和 / 在 URL 和文件名里有特殊含义，放进查询参数会被转义或截断，所以换成 - 和 _；结尾用来补齐长度的 = 在 URL 里同样碍事，常被直接省略。JWT 的三段就是这么编的。本页解码时会自动认出这两种写法并还原，不用你手工替换；编码时勾上「URL 安全字符集」就能输出这种形式。
Base64 没有「加密」，自然也谈不上「解密」，准确的说法是解码，而且一定能解开——把上面切到解码模式，粘进去点一下就是原文。它和 MD5、SHA-256 那种单向散列完全不同：后者不可逆，Base64 是完全可逆的双向编码。如果你看到有人用 Base64 来「加密」敏感数据，那是个安全问题，不是加密方案。
先看提示。本页解码后会尝试按 UTF-8 读，读不通就说明它本来就不是文本——是图片、PDF 或压缩包，这时会告诉你嗅探到的格式并给出下载按钮，直接下载才是正确操作，硬看当然是乱码。如果确定应该是文本却仍然乱，多半是原文用了 GBK 等非 UTF-8 编码，本页统一按 UTF-8 解，这种情况需要用支持指定字符集的工具。
三种常见情况：一是复制时漏掉了结尾几个字符，导致长度不是 4 的倍数且补不齐；二是内容里混进了 Base64 字母表以外的字符，比如从聊天记录里复制时带上了中文引号或省略号；三是这段字符串其实是 URL 编码（%3Chtml%3E 那种）而不是 Base64。换行和空格不会导致这个错误，本页会自动忽略。
Base64 用 4 个字符表示 3 个字节，所以固定膨胀到原来的 4/3，约多 33%，再加上末尾的补位字符。这是原理决定的，任何 Base64 工具都一样，不是本页的问题。如果体积敏感，正确的做法是先压缩再编码，或者干脆不内嵌、改用 URL 引用。
编码模式限制 10 MB。这个上限不是技术极限，而是因为再大就没有意义了：Base64 的用途是内嵌到文本里，一个 10 MB 的文件编完是 13 MB 的字符串，粘到哪里都会出问题。解码模式没有硬性上限，但浏览器处理超长字符串会变慢，几十 MB 的输入可能会卡一下。
不是。URL 编码（百分号编码）只把 URL 里的特殊字符换成 %XX，其余字符原样保留，结果人还能读个大概；Base64 会把全部内容重新表达成 64 个字符，结果完全不可读，但能安全承载任意二进制。两者经常一起出现：把 Base64 结果放进 URL 参数时，如果用的是标准字母表，里面的 + 和 / 还需要再做一次 URL 编码——这也正是 URL 安全变体存在的原因。
可以，但要注意字符集。Base64 处理的是字节不是字符，所以必须先把中文按某种编码转成字节。本页统一用 UTF-8，这也是目前的通行做法。同一段中文按 GBK 编码再 Base64，结果和 UTF-8 完全不同，两边对不上时先确认字符集，而不是怀疑 Base64 实现有问题。
不会。转换用的是浏览器内置的 atob / btoa 和 FileReader，文件读进内存、转换完直接显示，没有一个字节离开你的设备。页面加载完之后断开网络，这个工具照常可用——这是最直接的验证方法。详见隐私政策。