YWRtaW46c2VjcmV0Authorization: Basic YWRtaW46c2VjcmV0curl -H "Authorization: Basic YWRtaW46c2VjcmV0" https://example.com/api关于 Basic Auth 生成器
HTTP Basic 认证把用户名和密码用冒号拼接后做 Base64 编码，放进 Authorization: Basic <凭证> 请求头里传输。本工具在浏览器本地根据你输入的用户名和密码生成对应的 Base64 凭证和完整请求头，也能反向解码已有凭证查看其中的账号信息，便于调试受保护接口或配置 curl、Postman。所有处理均在浏览器本地完成，无需安装任何软件，它适合调试受保护接口、配置 curl 或 Postman 时快速生成 Authorization 头，也能反向查看已有凭证里的账号。例如输入用户名 admin 与密码 secret，会生成 Authorization: Basic YWRtaW46c2VjcmV0 请求头供测试接口。
基本认证是 HTTP 协议自带的最简单鉴权方式：把用户名与口令用冒号连接后做一次编码，放进请求头里随请求发送。它至今仍有明确用途——给内部接口、测试环境、监控端点加一道最低限度的门，或在对方只支持这种方式的集成场景里勉强可用；但它不适合承载真实业务的用户体系。 原理上最需要说清的一点是：这套机制只做编码，不做加密，因此必须运行在传输层加密之上，否则任何经过网络路径的人都能还原出明文凭据。字符串的编码是标准的二进制到文本的编码，不是哈希，也没有加盐，同一个用户名口令组合每次生成的请求头完全相同，这就带来两个后果：一是无法防重放，二是浏览器与中间层会把它当普通请求头缓存或在日志里打印出来。 使用要点：如果必须在服务端校验，应通过传输层加密并使用恒定时间比较，避免通过响应时间泄露口令长度或前缀；同时务必配合限流，因为这种方式的接口极容易成为暴力尝试的目标。前端调试时，注意到浏览器缓存凭据后很难「退出登录」——很多实现只有清空会话或换浏览器才能解除，测试时应预留一个干净配置环境。 边界与限制：无法单独登出、无法携带过期时间、无法表达权限范围，这三点决定了它只能用于最粗粒度的访问控制。它还会出现在代理日志、错误上报与浏览器开发者工具中，因此不应出现在任何面向公众的服务里。若需要通过链接分享给他人做临时访问，请改用带时效的一次性令牌，而不是把长期有效的凭据编码进地址。 数据与隐私：本工具用来生成与核对凭据字符串，输入的是真实用户名与口令，属于高敏感数据。转换全程在浏览器内完成，不上传内容；但更稳妥的做法是只输入结构与真实值相同的示例做格式核对，不要在在线工具里使用生产凭据。
误用主要是把它当成可用的用户体系：这套机制无法单独登出、无法携带过期时间、也无法表达权限范围，并且凭据会出现在代理日志、错误上报与开发者工具中，因此不适合任何面向公众的服务。另一个误用是在没有传输层加密的情况下使用，任何经过网络路径的人都能还原出明文口令。
实现原理
凭据是把用户名与口令按原文用冒号拼接后整体做一次编码，不做转义也不做哈希，因此它只是编码而非加密：必须运行在传输层加密之上，否则任何经过网络路径的人都能还原出明文。同一个用户名口令组合每次生成的请求头完全相同，所以无法防重放，也无法单独登出或设置有效期。
用户名 aladdin，口令 open sesameAuthorization: Basic YWxhZGRpbjpvcGVuIHNlc2FtZQ==（可用任意解码工具还原出明文）使用方法
- 打开「Basic Auth 生成器」
- 输入或粘贴待处理的内容
- 根据需要调整输出选项
- 点击「运行」按钮，结果实时显示
- 复制或导出结果
使用场景
- 调试受保护 API — 为 curl 或 Postman 快速生成 Authorization 头访问需认证的接口。
- 配置反向代理 — 在 Nginx 或网关里设置 Basic 凭证，验证账号密码是否编码正确。
- 解码排错 — 把抓包看到的 Basic 凭证还原成明文，确认调用方传了哪个账号。
- 内部服务保护 — 为 CI、监控面板等内网服务生成简单的 Basic Auth 凭证。
- 编写文档示例 — 在 API 文档里给出可直接复制的带认证头请求示例。
常见问题
Basic Auth 安全吗？
Base64 是可逆编码而非加密，凭证几乎等同明文传输。必须配合 HTTPS 使用，否则在网络中任何节点都能轻易解出用户名和密码。
用户名或密码含冒号怎么办？
规范规定用户名中不能包含冒号（因为冒号是分隔符），但密码中可以。解码时按第一个冒号拆分，因此密码里的冒号会被正确保留。
为什么非 ASCII 密码会出问题？
历史上 Basic 认证对非 ASCII 字符的编码没有统一规定，RFC 7617 建议使用 UTF-8。若服务端用了不同字符集，含中文的密码可能验证失败。
Basic 和 Bearer 有什么区别？
Basic 每次请求都带账号密码；Bearer 携带的是访问令牌（如 JWT），凭证可设置过期与权限范围，更适合现代 API。需要生成 JWT 可用本站相关工具。
凭证会被缓存吗？
浏览器在一次会话内可能缓存 Basic 凭证并自动附加到同源请求，因此退出登录往往需要关闭标签页或清除会话，这是 Basic 认证的固有局限。
浏览器一直重复弹出登录框，输入正确也不消失，是什么原因？
常见原因是服务端返回 401 时没有给出认证范围提示，浏览器无法判断这组凭据适用于哪个路径，于是对同一路径下的每个请求反复询问；另一种情况是凭据被缓存成了错误值，此时只关标签页不够，需要彻底退出浏览器进程或清除该站点的凭据记录。排查时先看响应头是否稳定返回 401，再确认凭据字符串前后没有多余空白。
用户名或口令里含冒号、中文等特殊字符还能用吗？
这种方式的凭据是把用户名与口令按原文用冒号拼接后整体编码，不做任何转义。用户名里出现冒号会让服务端从第一个冒号处切分，导致用户名与口令错位；中文等非 ASCII 字符则取决于客户端与服务端各自的字符集假设，容易出现本机能通过、服务端解出乱码的情况。稳妥做法是把用户名与口令都限制在可打印 ASCII 范围内。
生成的 Authorization 头直接能用吗？
能，格式是标准的 Basic base64(user:password)。但 Basic 认证明文传输凭据，必须配合 HTTPS 使用；同时很多现代 API 已改用 Bearer token，调用前确认服务端支持的认证方案，避免 401 后反复排查。