当你拿到一段看起来像乱码的文本，比如 SGVsbG8gd29ybGQ=，它很可能就是经过 Base64 编码的数据。Base64 解码的作用，就是把这种由 64 个可打印字符组成的字符串，还原成原本的人类可读文本或二进制数据。它的核心原理是逆向的 4 字符到 3 字节的映射：编码时每 3 个原始字节被转换为 4 个 Base64 字符，解码时则反过来，从 4 个 Base64 字符还原出 3 个字节，整个过程严格遵循 RFC 4648 标准。我们的 Base64 解码工具直接在浏览器中完成所有运算，你粘贴的字符串绝不会离开你的设备，同时还会自动处理缺失的填充和 URL 安全字母表。如果你需要把普通文本转换成这种格式，可以使用 Base64 编码 工具，让编码与解码形成完整的闭环。
拿到一段字符串，如何快速判断它是不是 Base64？你可以从三个特征入手。首先是字符集：标准 Base64 只包含大写字母 A-Z、小写字母 a-z、数字 0-9，以及加号 + 和斜杠 /。如果是 URL 安全版本，还会出现减号 - 和下划线 _。其次是长度规律：有效的 Base64 字符串长度通常是 4 的倍数，因为编码时每 3 个字节刚好变成 4 个字符。最后看填充：末尾经常会出现一个或两个等号 =，用来保证长度为 4 的倍数。但很多实现会省略填充，这种情况下我们的 Base64 解码工具依然能正确还原。举个中文例子：问候语 你好 编码后成为 5L2g5aW9，完全符合上述特征。如果一段字符串同时满足这些条件，十有八九就是 Base64。
即使你认出了 Base64，实际解码时也容易踩到一些坑。第一个是字母表混淆。标准版本用 + 和 /，而 URL 安全版本用 - 和 _，两者并不通用。如果用标准解码器强行处理 URL 安全的字符串，或者反过来，通常会得到无法阅读的内容。第二个陷阱是填充被随意去掉。有些编码器不输出末尾的 =，一旦解码器要求严格补齐就会直接报错。我们的 Base64 解码工具会自动补全缺失的填充，帮用户省去手动修复的麻烦。还有一个更隐蔽的问题是双重编码，也就是数据被连续 Base64 编码了两次。比如 YUdWc2JHOD0= 解码一次得到 aGVsbG8=，需要再解码一次才会出现真正的 hello。当你粘贴一段字符串，解码后看到的却依然像 Base64，多半就是遇到了双重编码，再次解码即可。
粘贴 Base64 后点击解码，得到的却是一堆不可读的符号或问号，这种情形在日常开发中很常见。先明确一个关键点：Base64 不仅用于编码文本，也广泛用来编码图片、音频、压缩包、加密数据等二进制内容。如果原始数据本身就不是 UTF-8 编码的文本，解码出来的自然就是“乱码”。这时你可以尝试将结果保存为文件，借助 Base64 转文件 工具来还原原始格式。缺失填充曾经是产生乱码或报错的常见原因，不过我们的 Base64 解码工具会自动处理，即使没有等号也能尽量还原。如果你在分析 JWT 令牌，其中间的载荷部分就是 URL 安全的 Base64，解码后若出现异常字符，可能是令牌被篡改或格式错误，可以配合 JWT 解码器 做专门解析。总之，遇到乱码先别慌，优先确认源数据的类型和编码。
不少初学者会误以为 Base64 是一种加密方法，用它来“保护”密码或敏感信息。这个想法非常危险。Base64 仅仅是编码，不是加密。任何拿到 Base64 字符串的人，都可以毫无障碍地将其解码回原始内容，整个过程没有任何密钥参与。即使你手动“加盐”或拼接字符串再编码，依然达不到加密应有的强度。我们的 Base64 解码工具完全运行在浏览器本地，你输入的数据不会上传到任何服务器，这一设计可以保护你在测试或临时解码时的隐私，但并不能把编码变成加密。真正需要保护的数据，请使用专业的加密算法。此外，从不可信来源获得的 Base64 数据，解码后可能包含可执行脚本或恶意指令，不要轻易运行。平时处理文件编码时，可以结合 文件转 Base64 工具来安全转换。
在网址参数、JWT 令牌或某些 Web API 的响应中，你经常会遇到一种“长相不同”的 Base64：它用减号 - 代替加号 +，用下划线 _ 代替斜杠 /，而且常常省略末尾的等号。这就是 URL 安全的 Base64。这样做的目的，是避免 +、/ 和 = 在 URL 中需要被百分号编码，让数据可以直接放在链接里。解码这种数据时，你完全不需要手动把字符替换回标准字母表，只要把字符串原样粘贴到 Base64 解码工具中，它会自动识别并完成解码。典型的例子是 JWT 的载荷部分，全部采用这种变体。如果你经常需要解析 JWT，不妨搭配 JWT 解码器 一起使用，效率会更高。输入中即使混入空格或换行，Base64 解码工具也会自动过滤，无需你提前清理。
Base64 字符串最明显的特征是只能包含 A-Z、a-z、0-9、加号（+）、斜杠（/）和等号（=）。合格的 Base64 文本长度通常是 4 的倍数，末尾可能出现一个或两个等号作为填充。如果字符串里出现中文、空格、标点符号，或者长度不是 4 的倍数且没有等号，一般就不是标准 Base64。但要注意 URL 安全格式会用减号（-）和下划线（_）代替加号和斜杠，看起来会略有不同。
这通常是因为原始数据根本不是文本，而是图片、音频等二进制文件，直接按 UTF-8 解码就会显示成一堆乱码。另外，如果原始文本使用了非 UTF-8 编码（比如 GBK），而我们这个工具统一按 UTF-8 字节解码，中文就可能出现乱码。还有一种情况是字符串本身不是合规的 Base64，解码逻辑出错。你可以先用 文件转为 Base64 验证字符串是否来自正确的编码流程，再由本工具解码。
不会。这个工具完全运行在你的浏览器里，你输入的 Base64 字符串和解码结果都只在本地处理，不会离开你的设备，也没有网络请求发给后台。所以即使你解码的是敏感数据，也不存在工具方泄露或收集信息的风险。如果你需要解码 JWT 令牌这类安全信息，同样可以放心使用，还能配合 JWT 解码器 查看载荷。
不会。本工具在解码之前会自动去掉输入里的所有空格、制表符和换行符，哪怕整个字符串被邮件客户端折行或从日志里复制的多余空行，都不会影响最终结果。你直接把带格式的文本粘贴进来就行，不用手动清理。
等号是 Base64 的填充符，用来把编码后字符串的长度凑成 4 的倍数。理论上每个等号代表一个填充字节。但是很多在线工具（包括这个）在解码时并不强制要求填充完整，即使缺少等号，只要字符串其他部分正确，照样可以正常解码出原始内容。不过为了兼容严格标准的系统，最好还是保留等号。
URL 安全格式会把标准 Base64 里的加号（+）替换成减号（-），斜杠（/）替换成下划线（_），并且通常去掉末尾等号，以便直接在 URL 参数里安全传递。这个工具同时支持两种格式，遇到减号和下划线会自动识别为 URL 安全格式并正确解码，无需手动转换。如果你经常需要编码生成 URL 友好的字符串，可以使用 Base64 编码 工具，它也会提供 URL 安全选项。
可以先用肉眼扫一遍：如果整段文字只由大小写字母、数字、加号、斜杠和等号组成，长度是 4 的倍数，就很大概率是 Base64。更可靠的办法是直接复制到本工具里面点解码，如果解码后变成了你认识的中文、英文或 JSON，就说明它确实是编码过的。反之，如果报了“输入不是有效的 Base64”或者解码出来还是不可读字符，很可能原本就是普通文本或二进制数据。
可以。解码完成后，页面会显示“下载”按钮，点击就能把结果保存为 .txt 文件，方便你存档或传给其他人。如果是解码二进制文件得到的内容，不建议用文本方式保存，这时候可以使用 Base64 转文件 工具，直接还原成原始格式的文件。
