Base64 编解码工具

Q: 编码中文时为什么容易乱码？

浏览器原生的 btoa() 只接受 Latin-1 范围内的字符，直接传入中文会抛 InvalidCharacterError；有人先用 escape() 转一道，就会得到乱码。正确做法是先 TextEncoder 编码成 UTF-8 字节数组再 Base64，解码时反之。本工具就是这么实现的。

Q: URL-safe Base64 和标准 Base64 有什么区别？

只有三处差异：+ 换成 -、/ 换成 _、省略末尾的 = 填充。原因是 + 在 URL 查询串里会被解析成空格，/ 会与路径分隔冲突。JWT、OAuth 的 token 用的都是 URL-safe 变体，代码里一般叫 base64url。

Q: 图片转 Base64 后能直接用在网页里吗？

可以，写成 <img src="data:image/png;base64,…"> 就行，浏览器不会再发额外请求。但要注意：体积比原图大约 1/3，且无法被单独缓存，大图会拖慢首屏并影响 SEO。建议只对小图标、纯色占位图使用，且优先 SVG。

Q: 内容会被上传到服务器吗？

不会。文本编解码使用浏览器原生的 TextEncoder / TextDecoder 与 btoa / atob，图片读取使用 FileReader，全部在本地完成，没有任何网络请求。处理内部接口数据、含敏感字段的配置时也可以放心使用。

编解码完全免费 🔒 本地处理不上传 🔁 双向互转 🖼️ 图片转 Data URI 🌙 支持黑夜模式

接口传参要 Base64、JWT 里那段看不懂的串、图片想塞进 HTML 或 CSS……文本与 Base64 双向互转，中文和 Emoji 都不乱码，还能把图片直接转成 Data URI 复制走。

类别程序员 · 编解码

运行方式纯前端 · 离线运行

编码标准UTF-8 → Base64 / URL-safe

图片上限单张 5 MB

🔤 文本编解码

输入内容

编码走 UTF-8，中文与 Emoji 都不会乱码；解码会自动补齐末尾的 = 填充。

📤 转换结果

请输入内容后点击「编码」或「解码」

🖼️ 图片转 Base64

用于 img src、CSS 背景、接口传图、前端本地缓存

点击选择图片，或把图片拖到这里支持 PNG / JPG / GIF / WebP / SVG，单张不超过 5 MB；图片只在本地读取，不会上传

同时输出 URL-safe 形态转换后可分别复制 Data URI、纯 Base64、URL-safe 三种结果

🕘 处理历史

本地保存最近 20 条，点击即可恢复

核心特性

文本 → Base64 编码，中文与 Emoji 不乱码

Base64 → 文本解码，自动补齐 = 填充

URL-safe 模式：+ / 换成 - _，末尾 = 省略

图片转 Data URI，支持预览与三形态复制

图片支持点击选择与拖拽上传

一键「结果回填」，编码解码来回验证

本地保存最近 20 条处理记录，点击即可恢复

支持黑夜模式与离线使用

Base64 到底解决什么问题？

Base64 是一种把任意二进制数据编码成可安全传输的纯文本的方式：它用 64 个可打印字符（A–Z、a–z、0–9、+、/）表示原始字节，每 3 个字节编码成 4 个字符，体积因此膨胀约 33%。它不是加密，任何人拿到都能解回原文，别用它藏密码。

它的价值在于「绕开限制」：HTTP 头、URL 查询串、JSON 字段、XML 文本节点这些地方只适合放可打印字符，塞二进制就会出问题；邮件附件（MIME）几十年来一直是 Base64；前端把图片直接写成 data:image/png;base64,… 就能省掉一次请求，小图标、骨架屏占位图尤其常用。

另一个高频场景是 URL-safe Base64：标准 Base64 里的 + 在 URL 中会被解析成空格，/ 会和路径分隔符冲突，所以 JWT、OAuth 等场景改用 - 和 _ 替换，并省略末尾的 = 填充。本工具两种形态都支持，勾一下开关即可切换。

中文乱码是最常见的坑：btoa() 只接受 Latin-1 字符，直接对中文调用会抛异常。本工具先用 TextEncoder 把文本转成 UTF-8 字节再编码，解码时反向用 TextDecoder 还原，因此中文、日文、Emoji 都能正确往返。所有计算都在浏览器本地完成，内容不会上传。

怎么用

粘贴文本

把要编码的内容粘进「输入」框，中文、Emoji、换行都支持；也可以直接粘一段 Base64 准备解码。
选择方向并执行

点「🔒 编码」把文本转成 Base64，点「🔓 解码」把 Base64 还原成文本；解不开时会明确提示哪一步失败了。
按需开启 URL-safe

要把结果放进 URL 或 JWT 时勾选「URL-safe」：+ → -、/ → _、去掉末尾 =；解码时同样勾选即可还原。
处理图片

在「图片转 Base64」区点击选择或拖入图片，立即得到预览与 Data URI，可分别复制 Data URI、纯 Base64、URL-safe 三种形态。
复制或回填

点「📋 复制」取走结果；想反向验证就点「⇄ 结果回填」，把结果填回输入框并自动切到解码。

使用技巧

Base64 不是加密，只是编码。敏感内容即使 Base64 过也不能当密文用，随手一解就出来了。
体积会膨胀约 1/3：3 字节变 4 字符。传大文件前请先想清楚，图片建议压缩后再转 Data URI。
看到末尾有 = 或 ==，那是填充符号，用来把长度补齐到 4 的倍数，解码前自动补上即可。
标准 Base64 里的 + 放进 URL 查询串会被解成空格，这就是需要 URL-safe 模式的根本原因。
Data URI 写进 CSS 时记得加上 url()，并且字符串里的 # 需要转义成 %23。

更新记录

v1.1 2026-09-11 重构页面：新增核心特性、上手步骤、使用技巧与 6 组常见问题，图片区支持拖拽上传并补充三形态复制说明，历史记录改为可点击恢复。
v1.0 2026-08-31 工具上线：文本 ↔ Base64 双向转换、URL-safe 模式、图片转 Base64（Data URI / 纯 Base64 / URL-safe 三形态复制）、历史记录本地保存；支持黑夜模式。

常见问题

Base64 是加密吗？能用来保护数据吗？

不是。Base64 只是编码，目的是把二进制数据变成可打印文本以便安全传输，任何人都可以一步解回原文。要保护数据必须用真正的加密算法（如 AES、RSA）。把 Base64 当加密用是常见误解，也容易造成数据泄露。

为什么 Base64 体积会变大？

它的原理是把每 3 个字节（24 位）重新切成 4 个 6 位单元，每个单元映射成 1 个可打印字符，所以 3 字节变成 4 字符，体积约为原来的 133%。如果原始长度不是 3 的倍数，还要补 = 填充满，因此实际膨胀率略高于 1/3。

编码中文时为什么容易乱码？

浏览器原生的 btoa() 只接受 Latin-1 范围内的字符，直接传入中文会抛 InvalidCharacterError；有人先用 escape() 转一道，就会得到乱码。正确做法是先 TextEncoder 编码成 UTF-8 字节数组再 Base64，解码时反之。本工具就是这么实现的。

URL-safe Base64 和标准 Base64 有什么区别？

只有三处差异：+ 换成 -、/ 换成 _、省略末尾的 = 填充。原因是 + 在 URL 查询串里会被解析成空格，/ 会与路径分隔冲突。JWT、OAuth 的 token 用的都是 URL-safe 变体，代码里一般叫 base64url。

图片转 Base64 后能直接用在网页里吗？

可以，写成 <img src="data:image/png;base64,…"> 就行，浏览器不会再发额外请求。但要注意：体积比原图大约 1/3，且无法被单独缓存，大图会拖慢首屏并影响 SEO。建议只对小图标、纯色占位图使用，且优先 SVG。

内容会被上传到服务器吗？

不会。文本编解码使用浏览器原生的 TextEncoder / TextDecoder 与 btoa / atob，图片读取使用 FileReader，全部在本地完成，没有任何网络请求。处理内部接口数据、含敏感字段的配置时也可以放心使用。

💬 留言板 0

全部留言需审核通过后展示

💬

还没有留言，来抢沙发吧！