Base64解码器
将Base64编码的字符串解码回其原始的纯文本或二进制表示。支持标准RFC 4648和URL安全的Base64字母表，包括JWT令牌。
Base64字符串在设计上是不透明的--SGVsbG8sIFdvcmxkIQ==在解码回Hello, World!之前是没有意义的。根据RFC 4648定义，Base64将每3个输入字节编码为4个输出字符，增加大约33%的开销。此解码器使用浏览器的原生atob()和TextDecoder API反转这一过程。它支持标准Base64和在JWT和OAuth令牌中使用的URL安全变体（-和_代替+和/）。没有任何内容被上传到任何服务器。
如何解码Base64
- 将您的Base64编码字符串粘贴到输入框中。
- 选择标准或URL安全模式，以匹配数据的原始编码方式。
- 解码后的纯文本会立即出现在输出面板中。
- 点击复制以复制结果。
Base64解码的工作原理
解码过程
解码正好是编码的反向操作。每个Base64字符都通过字母表表映射回其6位值。四个连续字符（24位）重构三个字节。浏览器的atob()函数原生处理标准Base64。对于URL安全的Base64，-和_在解码前会被转换回+和/。然后，将得到的UTF-8字节序列解码为Unicode字符串，使用TextDecoder。
处理缺失的填充
标准Base64需要=填充，以使字符串长度成为4的倍数。JWT和OAuth令牌去掉填充以减少大小。此解码器会根据字符串长度自动计算并添加所需的填充。如果字符串长度模4为2，则需要一个=；如果为3，则需要两个=字符。
示例
输入（标准Base64）
SGVsbG8sIFdvcmxkIQ==输出
Hello, World!常见用例
- JWT令牌检查 - 解码头部和有效负载部分，以便在没有库的情况下读取声明
- HTTP基本认证 - 解码
Authorization: Basic dXNlcjpwYXNz头以验证嵌入的凭据 - 数据URI检查 - 解码
data:image/png;base64,...URI的Base64部分 - API响应调试 - 一些API在JSON响应中Base64编码二进制内容
最佳实践
- 选择正确的模式（标准与URL安全）--使用错误的模式会产生乱码输出
- 对于JWT令牌，仅解码头部（第一部分）和有效负载（第二部分）；第三部分是加密签名，而不是编码文本
- 如果输出是无法读取的字符，则源数据是二进制（图像、PDF等），而不是文本
- Base64解码不是安全检查--任何人都可以解码它
要将文本编码回Base64，请使用Base64编码器。对于URL编码的数据，请使用URL解码器。要完全检查JWT，请选择URL安全模式单独解码前两个用点分隔的部分。
常见问题
我如何使用此工具解码JWT令牌？
JWT由三个部分组成，用点分隔：header.payload.signature。复制头部（第一部分）或有效负载（第二部分），选择URL安全模式，然后将其粘贴到解码器中。输出是包含算法（头部）或声明（有效负载）的JSON对象。请勿解码签名--它是一个加密哈希，而不是Base64编码的JSON字符串。
为什么我的解码输出显示奇怪的字符？
这可能有三种情况：（1）原始数据是二进制（图像、PDF、zip）而不是文本；（2）您选择了错误的模式--尝试在标准和URL安全之间切换；（3）原始文本使用了UTF-8以外的字符集进行编码。首先尝试切换模式。如果输出仍然无法读取，源数据可能是二进制的。
解码时需要填充字符（==）吗？
标准Base64需要填充以使字符串长度成为4的倍数。此解码器会自动添加缺失的填充，这对于去掉尾部=字符的JWT和OAuth令牌非常重要。按原样粘贴字符串，解码器会自动处理填充。
在这里解码时我的敏感数据安全吗？
是的。解码完全在您的浏览器中运行，使用原生atob()和TextDecoder API。您粘贴的令牌、凭据和私密数据从未发送到任何服务器，永远不会被记录或存储。在解码时打开浏览器的网络标签，您将看到没有外发请求。
标准Base64和URL安全Base64有什么区别？
标准Base64（RFC 4648 §4）使用+和/。URL安全的Base64（RFC 4648 §5）用-和替换它们，以避免在URL、文件名和HTTP头中发生冲突。JWT、OAuth令牌和PKCE代码验证器都使用URL安全的Base64。如果您的字符串包含-或，请选择URL安全模式。