← 返回工具箱

开发 / HTTP 认证

Basic Auth Header 编码解码

生成 Authorization Header、curl 和 fetch 请求，也能把已有 Basic Token 拆回用户名与密码。凭据只在当前浏览器内处理，不会保存到本地存储。

Basic Auth 只是把 user-id:password 做 Base64 编码，任何拿到 Header 的人都能还原。 正式环境必须使用 HTTPS，下载或截图前也要确认没有暴露真实凭据。
字符编码

Base64 Token

c2VhbDpzdHVkaW8=

Authorization Header

Authorization: Basic c2VhbDpzdHVkaW8=

curl：--user

curl --user 'seal:studio' 'https://example.com/api'

curl：手动 Header

curl --header 'Authorization: Basic c2VhbDpzdHVkaW8=' 'https://example.com/api'

Fetch

fetch("https://example.com/api", {
  headers: {
    Authorization: "Basic c2VhbDpzdHVkaW8=",
  },
});

冒号怎样处理

RFC 7617 以第一个冒号分隔用户名和密码，所以用户名不能含冒号，密码可以。解析时后续冒号全部保留在密码中。

UTF-8 不是自动保证

服务端可在 WWW-Authenticate 挑战中声明 charset="UTF-8"。旧系统可能沿用兼容编码，遇到中文乱码应核对服务端文档。

不要把凭据写进前端

浏览器 fetch 示例只适合调试受控接口。公开网页源码、日志、错误追踪和 Git 仓库都不应包含仍在使用的账号密码。

RELATED TOOLS

接着处理

查看全部工具 →
Base64 编码解码单独检查文本与二进制 Base64，不附加 Basic 认证语义。HTTP Header 解析检查完整请求或响应头中的认证、缓存和内容类型。cURL 代码转换把完整 cURL 请求转换成 Fetch、Axios、Python 等代码。htpasswd 生成器生成服务端密码文件条目，不要与 Basic Header 的 Base64 混淆。

USE & REVIEW

Basic Auth Header 生成 / 解析常见问题

查看全部工具指南 →

Basic Auth 的 Base64 是加密吗？

不是。Base64 只是可逆编码，拿到 Authorization Header 的人可以直接还原用户名和密码。Basic Auth 必须放在 HTTPS 连接里使用，还要避免把真实 Header 留在截图、日志、监控报错、前端源码或 Git 仓库中。

为什么用户名不能包含冒号，密码却可以？

RFC 7617 把凭据拼成 user-id:password，并用第一个冒号作为分隔符，所以 user-id 中出现冒号后无法无歧义解析。密码里的后续冒号会被当作密码内容保留；本工具的解析器也只在第一个冒号处分开。

Basic Auth 应该使用 UTF-8 还是 Latin-1？

RFC 7617 允许服务器在 WWW-Authenticate 挑战中通过 charset="UTF-8" 表明 UTF-8，且建议新系统支持 UTF-8。部分旧服务沿用单字节兼容方式，因此工具保留 ISO-8859-1 选项。含中文或其他非 ASCII 字符时，应以目标服务文档和真实请求结果为准。

解析器可以粘贴哪些格式？

可以粘贴纯 Base64 Token、以 Basic 开头的值，或完整的 Authorization: Basic ... Header。自动模式会先按严格 UTF-8 解码，字节无效时再按 Latin-1 兼容方式还原，并给出提示；它不会验证这组凭据能否登录远端服务。

生成的 curl 和 Fetch 为什么仍可能请求失败？

Header 正确只解决认证格式。目标还可能受到 CORS、代理、证书、网络、请求方法、Content-Type、账号权限或服务端认证策略影响。浏览器 Fetch 尤其受同源与 CORS 限制；请先用测试账号在目标环境验证，不要把失败简单归因于 Base64。

这个页面会保存我输入的账号密码吗？

生成、编码和解析都在当前浏览器内完成，页面没有把凭据写入本地存储或提交到服务器。浏览器扩展、系统剪贴板、下载文件和屏幕共享仍可能接触内容，因此只使用测试凭据最稳妥，完成后应清空输入并删除不再需要的导出文件。