Base64 编解码
中文不会乱码，URL-safe 变体直接可用，解码失败会告诉你具体是哪一步不对。 纯前端处理——粘贴的密钥、令牌不会被上传。
输入文本
输出
Base64 不是加密
这是最常见的误解。Base64 是一种编码方式，作用是把任意字节映射成 64 个可打印字符，方便在只能传文本的通道里传二进制数据。 它不提供任何保密性——任何人拿到 Base64 字符串都能一行代码还原。
所以：把密码、密钥 Base64 之后存起来，等于没加密。 真正需要保密要用 AES 这类加密算法，Base64 只能负责「让密文能安全地放进文本字段」。
三个容易踩的坑
| 坑 | 原因 | 怎么办 |
|---|---|---|
| 中文解码回乱码 | 编码和解码用的字符集不一致。JS 原生 btoa() 只处理 Latin-1，直接喂中文会报错或乱码 |
先按 UTF-8 转成字节再编码。这个工具已经处理好了 |
| 放进 URL 后参数被截断 | 标准 Base64 含 +、/、=，这些字符在 URL 里有特殊含义（+ 会被解析成空格） |
用 URL-safe 变体：+→-、/→_、去掉 = |
末尾少几个 = |
很多系统（JWT、部分 API）会省略末尾的填充符，严格解码器会报错 | 这个工具会自动补全 padding，不用手工数 |
什么时候用到
- HTTP Basic 认证：
Authorization: Basic base64(user:pass)——调接口报 401 时，先确认这里的编码对不对。 - JWT：header 和 payload 两段就是 Base64URL 编码的 JSON，用JWT 解析可以直接看内容。
- 内嵌小图片：
data:image/png;base64,...能省一次请求，但体积会涨三分之一，只适合很小的图。 - 接口里的二进制字段：有些 API 用 JSON 传文件内容，就是 Base64。
常见问题
Base64 是加密吗？
不是，完全没有保密作用。Base64 只是把字节映射成 64 个可打印字符，
编解码是公开的、可逆的，任何人都能还原。
把密钥 Base64 之后再存进配置，安全性没有任何提升—— 它只是让内容能安全地放进文本字段（比如 HTTP 头或 JSON）。
把密钥 Base64 之后再存进配置，安全性没有任何提升—— 它只是让内容能安全地放进文本字段（比如 HTTP 头或 JSON）。
为什么编码之后内容变长了？
Base64 用 4 个字符表示 3 个字节，所以体积约为原来的
133%，也就是增加约三分之一（
这就是为什么「用 Base64 内嵌图片」只适合很小的图——大图会明显变大，而且无法被浏览器缓存。
n 字节 → 4×⌈n/3⌉ 字符）。
这就是为什么「用 Base64 内嵌图片」只适合很小的图——大图会明显变大，而且无法被浏览器缓存。
URL-safe 的 Base64 有什么不一样？
标准 Base64 的字母表里有
URL-safe 变体（RFC 4648 §5）把它们换成
JWT 用的就是这一种。
+ 和 /，这两个字符在 URL 里有特殊含义
（+ 在查询字符串里代表空格）。
URL-safe 变体（RFC 4648 §5）把它们换成
- 和 _，
并且通常省略末尾的 =，这样就能直接放进 URL 路径或文件名。
JWT 用的就是这一种。
中文解码回乱码是什么原因？
说明编码和解码用的字符集不一致。
JS 原生的
这个工具已经按 UTF-8 处理，所以中文不会乱码。 如果你在别处遇到乱码，检查那一端是不是用了 GBK。
JS 原生的
btoa() 只能处理 Latin-1，直接传中文会抛异常。
正确做法是先把字符串按 UTF-8 转成字节数组再编码，解码时再按 UTF-8 还原。
这个工具已经按 UTF-8 处理，所以中文不会乱码。 如果你在别处遇到乱码，检查那一端是不是用了 GBK。