Base64 在线编码解码
文本与图片的 Base64 编解码，支持中文 UTF-8 与 URL-safe 模式，也能把 Base64 还原成图片。
把图片内联进 HTML、给接口传二进制、确认一段 Base64 到底是图片还是乱码，是前端和运维都会遇到的场景。常见的麻烦也很固定：用 btoa 直接编码中文会报错，从证书或邮件里复制来的 Base64 带着换行和空格，放进 URL 时 + 与 / 又被转义。
编码解码全部由浏览器内置的 TextEncoder、TextDecoder 和 FileReader 完成，图片拖进来只在本机读取，不会发起任何上传请求，断网同样可用。URL-safe 选项对应 RFC 4648 的 - 与 _ 变体，粘贴内容中混入的换行与空格会被自动忽略。
Base64 是编码不是加密
Base64 做的事是把每 3 个字节按 6 位重新分组，映射到 A-Z、a-z、0-9、+、/ 这 64 个字符上，末尾不足的位置用 = 补齐。整个过程没有密钥、完全可逆，任何人拿到字符串都能还原出原始数据，所以它可以用来传输，但绝不能用来保护密码、Token 或隐私字段。真正需要保密要使用 AES、RSA 这类加密算法，并且把密钥单独管理。
中文为什么要先转 UTF-8
浏览器原生的 btoa 只接受码点小于 256 的 Latin-1 字符，直接传中文会抛 InvalidCharacterError；即使先转成二进制再编码，解码端也会得到乱码。正确做法是先用 TextEncoder 把字符串编成 UTF-8 字节数组再做 Base64，解码时先还原字节、再用 TextDecoder 按 UTF-8 解回字符串，这样中文和 emoji 都不会出错。这也是不同工具之间结果对不上的常见原因。
URL-safe 变体与换行处理
标准 Base64 使用的 + 和 / 在 URL、文件名以及部分 MIME 场景里有歧义，RFC 4648 定义的 URL-safe 变体用 - 和 _ 替代它们，末尾的 = 也常被省略，JWT 采用的就是这种写法。另外 PEM 证书、邮件附件会每隔若干字符插入换行，从这些地方复制出来的内容常带换行与空格，直接解码会失败，本工具会自动忽略这些空白字符。
常见问题
- Base64 能用来加密数据吗？
- 不能。Base64 没有密钥，只是把字节重新编码成 64 个可打印字符，任何人都能一步还原，所以它属于编码而不是加密。把密码或敏感字段做一次 Base64 再传出去，等同于明文传输，只是看起来不像而已。
- Base64 编码后体积会变大多少？
- 大约膨胀 33%。原始数据每 3 个字节变成 4 个字符，末尾的 = 补齐还会再占一点，100 KB 的文件编码后接近 134 KB。这也是不建议把大图片转成 Base64 直接内联进 HTML 或接口的原因。
- 为什么 btoa 编码中文会报错或乱码？
- btoa 只接受 Latin-1 范围内的字符，中文码点超出范围就会抛 InvalidCharacterError；用 escape/unescape 绕过得到的是 Latin-1 字节，解码端按 UTF-8 读就会乱码。正确做法是先用 TextEncoder 得到 UTF-8 字节再编码。
- 图片转成 Base64 直接内联有什么坏处？
- HTML 或 CSS 体积变大，而且这段字符串无法被单独缓存，浏览器每次加载都要重新解析，首屏反而更慢，图片也没法懒加载。建议只对小图标使用，大图仍走独立图片文件加 CDN。