Base64 编解码
把文本编码成 Base64 或把 Base64 解码回文本，支持 URL 安全字符集与中文、Emoji 等 Unicode 内容。
浏览器本地运行所有计算都在你的浏览器里完成，数据不会离开本机。
结果
这个工具能做什么
- 把二进制不友好的文本塞进只能传 ASCII 的通道：HTTP 头、URL 查询串、JSON 字符串、邮件头、XML 属性等。
- 解 JWT、Basic Auth、Data URL、邮件源码里那种「看着像乱码」的字段，快速判断里面到底是什么内容。
- 排查编码问题时对照字节数：同一段中文在 Base64 里通常比原文长三分之一，可以用这个比例反推原文长度。
- 把不可见字符（换行、制表符、控制字符）编成可复制的可见文本，再粘到聊天工具或工单里传递。
示例
输入
Hello, UniKit! 你好，工具站！
输出
SGVsbG8sIFVuaUtpdCEg5L2g5aW977yM5bel5YW356uZ77yB
中文和 Emoji 会先按 UTF-8 编码再转 Base64，所以解码时必须用同样的字符集，否则会出现乱码。
常见问题
Base64 是加密吗？
不是。Base64 只是把任意字节映射成 64 个可打印字符的编码方式，任何人都能一行代码解回来，它不提供任何保密性。要保密请用 AES 之类的加密工具，Base64 只解决「能不能安全传输」的问题。
为什么编码后的内容末尾有一两个等号？
Base64 每 3 个字节编成 4 个字符，原文长度不是 3 的倍数时用 = 补位。一个 = 表示原文长度除以 3 余 2，两个 = 表示余 1。补位只影响长度对齐，不携带信息，所以很多场景（如 URL、JWT）会直接去掉它。
URL 安全字符集是什么，什么时候该勾选？
标准 Base64 的字母表里有 + 和 /，这两个字符在 URL 里有特殊含义，放进查询串会被当成空格或路径分隔符。勾选后会用 - 和 _ 替换它们并去掉补位的 =，这就是 RFC 4648 定义的 base64url，JWT、Data URL 都用它。
解码报「不是合法的 Base64」或乱码是怎么回事？
三种常见原因：字符串里混进了空格或换行（勾选「忽略空白字符」即可）；原文是用 GBK 等非 UTF-8 编码生成的，需要用字符集转换工具先转码；内容被截断，长度不是 4 的倍数且无法补位。
我的数据会被上传吗？
不会。编解码全部在你的浏览器里用 JavaScript 完成，页面不发送任何网络请求，输入内容也不会被记录。断网状态下同样可以使用。
关键词：base64base 64encodedecode编码解码url safeunicodebase64 转换