快速开始
-
输入原文或 Base64
中文、emoji、特殊字符都可处理。
-
选择编码或解码
点击按钮后立即输出结果。
-
复制结果
一键复制用于 API 请求或配置。
Base64 编码/解码
Base64 将二进制数据编码为 ASCII 文本，常见于 Authorization 头、Data URL 与 JWT 片段，但它是编码而非加密。本工具支持 UTF-8 双向转换（含中文与 emoji），全部在浏览器本地完成。调试 Basic Auth 或 OAuth 时可配合 jwt-decoder 与 url-encoder 理解多层编码叠加。
阅读完整指南: Base64 与 URL 编码：区别、场景与常见错误 →
隐私提示：本地解析，不上传服务器。
↓ 在下方输入区粘贴内容，结果会立即显示
在此输入文本或 Base64
支持中文与 emoji，选择编码或解码后查看结果。
Base64 将二进制数据编码为 ASCII 文本，常见于 Authorization 头、Data URL 与 JWT 片段，但它是编码而非加密。本工具支持 UTF-8 双向转换（含中文与 emoji），全部在浏览器本地完成。调试 Basic Auth 或 OAuth 时可配合 jwt-decoder 与 url-encoder 理解多层编码叠加。
Base64 不是加密
Base64 只是将每 3 字节映射为 4 个可打印字符，便于在 JSON、HTTP 头、XML 中传输。没有密钥、没有完整性保护。把 API Key 做 Base64 不等于「加密存储」——攻击者解码即可得到原文。
需要保密时请使用 TLS 传输 + 服务端密钥管理（KMS/Vault），而非依赖 Base64 混淆。
常见场景与坑
HTTP Basic Auth 的 `Authorization: Basic dXNlcjpwYXNz` 即 `user:pass` 的 Base64。调试 OAuth 时 JWT 的 Header/Payload 段也是 Base64URL（`-`/`_` 变体，可忽略 padding）。
解码失败常见原因：URL 安全字符未还原、padding `=` 被截断、把 Base64 当 UTF-8 直接显示（乱码）。本工具按 UTF-8 解码文本；二进制文件请用专用工具。
配合 **jwt-decoder** 理解 Token 各段，**url-encoder** 处理查询参数中的编码叠加问题。
安全使用建议
勿在工单中粘贴含真实凭证的 Base64 串。分享样本时用假用户名/密码重新编码。处理完成后清空输入。
编码与加密的根本区别
Base64 将每 3 字节映射为 4 个可打印 ASCII 字符，使二进制数据能安全嵌入 JSON、XML 与 HTTP 头——它没有密钥、不提供机密性，任何人拿到字符串都能解码。把 API Key 做 Base64「混淆」不等于加密存储；攻击者解码即可得到原文。真正保密需要 TLS 传输加密、服务端 KMS/Vault 管密钥，以及 bcrypt 等专门算法存储密码。
与 hash-generator 不同，Base64 可逆；与 url-encoder 不同，Base64 处理字节而非 URL 保留字符规则。JWT 的 Header/Payload 使用 Base64URL（-/_ 替代 +/，padding 可省略），调试 OAuth 时可配合 jwt-decoder 对照各段原文。
UTF-8 与二进制边界
本工具按 UTF-8 编解码文本，正确处理中文、emoji 与组合字符。若源数据是 PNG、PDF 等二进制，浏览器端直接当 UTF-8 解码会产生乱码或替换字符——此类场景应使用 FileReader 或命令行 base64 命令，并明确 charset。Data URL（data:image/png;base64,...）需先剥离 MIME 前缀再解码。
编码后体积约增 33%。在 JWT 或 Cookie 中塞大量 Base64 payload 会影响请求头大小限制（常见 8KB）。设计 API 时优先 JSON 字段而非嵌套 Base64 字符串，除非传输 truly binary。
HTTP Basic Auth 与常见坑
Authorization: Basic dXNlcjpwYXNz 即 user:pass 的 Base64，非加密。调试 REST 客户端时，可用本工具验证用户名密码拼接是否正确（注意 colon 分隔符）。HTTPS 必须保护传输层；否则 Base64 凭证可被中间人直接解码。与 Bearer JWT 不同，Basic 凭证通常长期有效，泄露风险更高。
解码失败常见原因：URL 安全变体未还原（+ 被当作空格）、padding = 被截断、字符串中混入换行或引号。部分库输出无 padding 的 Base64URL——JWT 场景可忽略 padding，但通用解码可能需要手动补 = 至长度为 4 的倍数。
与 Towalles 工具链协作
jwt-decoder 展示 token 各段解码结果；若 claim 值仍是 Base64 嵌套字符串，回到本工具二次解码。url-encoder 处理 query 中的 %XX 层，当 Base64 作为 query 参数传输时，常先 url-encode 再 Base64 或相反——出错时逐层还原。hash-generator 生成不可逆摘要，用于校验完整性而非传输原文。
分享调试样本时用假凭证重新编码，勿粘贴生产 Basic 头或含私钥的 PEM Base64。处理完毕清空输入；浏览器扩展与录屏软件仍可能捕获屏幕内容。
JWT 与 Data URL 中的变体
JWT 使用 Base64URL：用 -_ 替代 +/，且常省略 padding =。标准 Base64 与 Base64URL 互转错误会导致 jwt-decoder 失败。Data URL（data:image/png;base64,…）则是标准 Base64；不要把 JWT 段当图片 Data URL 解码。
Basic Auth 的 user:pass 经标准 Base64；配合 url-encoder 理解「Authorization 头再放入 URL」的叠层错误。
不是加密：固定流程说明
Base64 可逆且无密钥。任何「加密传输」若仅 Base64，等同明文。教学演示可用本工具瞬间还原，以打破误解；真正机密应使用 TLS 与正确密码学（见 hash-generator、bcrypt、jwt 验签分工）。
粘贴可能含密钥的 Base64 前先分级；处理完清空输入。本地解码不上传，但屏幕共享与剪贴板仍会泄露。
邮件、证书与 PEM 往返
PEM 块（BEGIN CERTIFICATE）内部是 Base64 行折叠；复制时勿混入 BEGIN/END 行再解码正文。邮件 MIME 的 Base64 也可能软换行。先拼成连续 Base64 再解，再用哈希工具核对导出的 DER 字节。
若解码结果以乱码显示，可能是二进制：改为下载字节或用 hex 工具查看，而不是当 UTF-8 文本阅读。
示例
编码示例
Input
hello
Output
aGVsbG8=
解码示例
Input
5L2g5aW9
Output
你好
FAQ
为什么解码报错？
输入含非法字符、长度不是 4 的倍数、或 padding 被截断。检查是否混入了 URL 编码（%3D）或换行。
支持 UTF-8 吗？
支持。中文、emoji、组合字符均可正确编解码。
和 Base64URL 一样吗？
标准 Base64 使用 +/ 与 = padding；JWT 等使用 Base64URL（-_）。本工具面向通用 Base64；JWT 段请用 **jwt-decoder**。
数据会上传吗？
不会。编解码在浏览器本地完成。
Base64 能用于密码保护吗？
不能。Base64 无密钥、可逆，任何人可解码。密码存储应使用 bcrypt（见 Towalles bcrypt 工具）或 Argon2；传输应使用 HTTPS。Base64 仅适合编码而非保密。
Base64 与 Base64URL 有何不同？
Base64URL 将 +/ 替换为 -/_，并常省略末尾 = padding，以便安全嵌入 URL 与 JWT。解码 JWT 段时通常用 Base64URL 规则；本工具处理标准 Base64，JWT 调试建议配合 jwt-decoder。
为什么中文解码后是乱码？
常见原因是把 Latin-1 或错误 charset 的 bytes 当 UTF-8 显示，或源文本并非 Base64。确认编码端使用 UTF-8，并检查 Base64 字符串是否完整无截断。示例：5L2g5aW9 正确解码为「你好」。
编码会显著增加请求体积吗？
Base64 体积约为原二进制 4/3。小字符串影响可忽略；嵌入大文件于 JSON 时考虑改用附件 URL 或二进制上传端点，而非 inline Base64。
为什么解码出乱码？
常见原因：Base64URL/标准混用、缺 padding、或原文并非 UTF-8 文本（实为二进制）。
能当密码存储吗？
不能。Base64 不是哈希也不是加密。
padding = 可以删吗？
标准 Base64 解码器常需要 padding；Base64URL 常省略。按目标规范补齐或选择正确变体。