Base64 编码 / 解码
编码和解码 Base64、Base64URL、Base32 与十六进制——文本边输入边转换，文件可拖放——解码器足够严格，能告诉你第一个不该出现的字符的确切位置，而不是含糊其辞。一切都在你的浏览器中运行：人们解码的字符串往往正是令牌和密钥，把它们发给服务器、或粘贴进有日志记录的 AI 对话，恰恰是解码器绝不能要求你做的事。
文件
把文件拖到这个框里的任意位置，即可按上方所选格式编码——你会得到编码后的文本和一个现成的 data URL。也可以把编码文本粘贴到这里，把解码出的字节下载为文件。
四种字母表，同一件事
四种格式做的都是同一件事——只用安全、可打印的字符来书写任意字节——只是面向不同的场景。标准 Base64 是电子邮件附件、配置文件和无数 API 的默认选择。Base64URL 把会破坏 URL 的两个字符（+ 和 /）换成 - 和 _，并去掉填充，是每个 JSON Web Token 内部使用的字母表——用 JWT 解码器解开一个令牌，三段全都是这种格式。Base32 使用更小的、不区分大小写的字母表，能经受朗读和手工录入，所以 TOTP 验证器密钥用它发放。Hex 让体积翻倍，换来完全的透明：一字节、两字符、无所隐藏——这正是哈希的格式，哈希生成器生成它，哈希识别器辨认它。
这里的严格是有意为之，它正是解码器和调试工具的区别。像 atob() 这样的浏览器内置函数，对“第 4 位有个错字”的字符串和“根本不是 Base64”的字符串只会抛出同一个笼统错误。本解码器逐字符校验，报告第一个出错的位置——从 JSON 里拖进来的一对引号、本该用 URL 安全字母表却出现的一个 +、卡在中间的填充、或是最后一个字符溢出的比特不为零（说明字符串在编码之后被改过）。九成“解不开”的谜团，在有人指出那个位置之后就一目了然。又因为这类工作常常涉及凭据——Kubernetes 密钥就是 Base64（是编码，从不是加密）、令牌载荷、配置文件里的密钥——整个转换都在本地完成，遵循与 .env 校验器相同的规则：敏感输入绝不传输。配套文章 Base64 不是加密 更完整地论述了这一区别为何重要。
常见问题
Base64 是一种加密吗？
不是。Base64 是一种编码——一种没有密钥、没有保密性的可逆换装。任何人看到 Base64 字符串都能立刻解码，所以“API 密钥在配置里是 Base64 编码的”就等于“API 密钥在配置里是明文”。文章 Base64 不是加密 厘清了编码、加密与哈希，以及混淆它们各自会造成的错误。
为什么这个解码器能告诉我错误的确切位置？
因为只说“无效字符”却不给位置，正是普通解码器浪费你一下午的方式。粘贴的字符串通常死于三个原因之一：混入了周围文本的杂散字符（引号、逗号、一行日志）、用错了字母表（把 URL 安全字符串喂给标准解码器）、或者复制时被截断。这里会指出第一个出错的字符及其下标，你可以盯着那个位置看，判断究竟是哪一种。
Base64 与 Base64URL 有什么区别？
字母表不同。标准 Base64 使用 + 和 /，它们在 URL 里是结构字符，所以 URL 安全的 Base64 把它们换成 - 和 _，并且通常去掉 = 填充。每个 JWT 内部用的都是这一种。把一种喂给另一种的解码器，是在第一个 + 或 / 的位置解码失败的最常见原因——本工具把各个模式分开，错误信息才能告诉你发生的正是这件事。
在这里解码令牌或密钥安全吗？
安全——转换在你的浏览器、在本页面内运行，你粘贴的任何内容都不会被传输或存储。这一点很重要，因为人们解码的东西往往正是凭据：配置文件里的 Base64 数据块、Kubernetes 密钥（那是 Base64，不是加密——见上一个问题）、令牌的载荷。把同一字符串粘贴进 AI 对话，等于把一份副本发送给一个有日志的第三方系统；见 不要让聊天机器人碰你的密钥。
为什么我的文件解码时显示“不是有效的 UTF-8”？
因为它是二进制——图片、压缩包、任何编译产物——而二进制不是文本。文本解码器会拒绝，而不是把乱码交给你。请用文本框下方的“文件”区域：把 Base64 粘贴到那里，下载字节完好无损的重建文件。