Basic Auth Header Generator

Build an HTTP Basic Authorization header from credentials.

Username

Password

Header

Authorization: Basic YWRtaW46czNjcjN0

Encoded Credentials

YWRtaW46czNjcjN0

How HTTP Basic Auth works

HTTP Basic Authentication sends credentials in an Authorization header as Basic <base64(user:password)>. Base64 is encoding, not encryption — anyone who intercepts the header can trivially decode it, so Basic Auth must only be used over HTTPS. This tool builds the header locally in your browser; your credentials are never sent anywhere.

Built and maintained by Meet Shah · Last updated 1 August 2026

What this tool is used for

Building an Authorization header for a curl command or an API client.
Reproducing a request from a captured trace to check which credential it used.
Testing an endpoint's auth before wiring up a client library.
Producing a header value for a config file or a CI secret.
Checking that a credential with special characters encodes correctly.

Frequently Asked Questions

How is the header constructed?: Authorization: Basic followed by the Base64 of username:password. Defined in RFC 7617. The colon is a separator, so a username containing one cannot be represented — a genuine limitation of the scheme.
Is Base64 here providing any security?: None whatsoever. It is a transport encoding to keep the header ASCII-safe, and it is trivially reversible. Basic Auth is only safe over TLS, where the whole header is encrypted in transit.
How are non-ASCII characters handled?: Badly, historically — the RFC now recommends UTF-8 before Base64 encoding, but older servers assumed Latin-1. A password with accented characters can therefore authenticate against one server and fail against another.
How does this differ from Bearer?: Basic sends reusable credentials on every request; Bearer sends a token that was issued after authentication and can be scoped and expired. Bearer is preferred for APIs precisely because the long-lived secret is not repeatedly transmitted.
Should I hard-code this header?: No. An embedded Basic header is a plaintext credential in your source — trivially decoded by anyone with repository access. Read it from an environment variable or secret store, exactly as you would the password itself.
Why is Basic auth acceptable over HTTPS and not otherwise?: Because the credential is encoded, not encrypted — Base64 is reversible by anyone. Over TLS the transport protects it; over plain HTTP it travels in effectively clear text on every single request, which is the worst property a credential scheme can have.
How does the browser prompt relate to the header?: A 401 carrying `WWW-Authenticate: Basic realm="…"` is what triggers the native dialog, after which the browser attaches the header automatically to subsequent requests. That automatic caching is also why logging out of Basic auth is so awkward.

Common errors and gotchas

Thinking Base64 protects the credential. It is encoding, not encryption, and decodes in one step.
Forgetting the `Basic ` prefix, which the header requires before the encoded value.
Omitting the colon between username and password, which produces a header the server cannot split.
Using it over plain HTTP, where the credential travels in effectively plain text.
Pasting the generated header into a shared document or a ticket, which leaks the credential.