Authorization Header Generator — Basic & Bearer

Build a ready-to-paste Authorization header: Basic auth base64-encoded from a username and password, or a Bearer token. Free, instant, client-side.

🔒 100% Client-Side Processing

Your data is processed entirely in your browser and never transmitted to any server.

Example

Input

admin : s3cret

Output

Authorization: Basic YWRtaW46czNjcmV0

The username and password are joined with a colon and base64-encoded as UTF-8. That value decodes straight back to admin:s3cret, which is why Basic auth is only safe over HTTPS.

Fill the fields above to build the header.

Common Use Cases

Testing an endpoint that uses Basic auth

Turn a username and password into the exact header string to paste into a request, a curl command, or an API client.

Building a Bearer header for a token

Wrap an OAuth access token or JWT in the correct Authorization format without misremembering the scheme prefix or spacing.

Explaining why Basic auth needs HTTPS

Show a colleague how quickly that base64 decodes back to a plaintext password — usually more persuasive than describing it.

Frequently Asked Questions

Is Basic auth base64 a form of encryption?
No, and treating it as one is the single most common mistake with Basic auth. Base64 is a reversible encoding with no key: anyone who sees the header decodes it back to your username and password in one step. RFC 7617 is explicit that the scheme provides no confidentiality on its own. It is acceptable only over HTTPS, where TLS protects the header in transit, and never over plain HTTP, in a URL, or anywhere headers get logged.
What exactly gets base64-encoded?
The username and password joined by a single colon, encoded as UTF-8, then base64'd — so user "admin" with password "s3cret" becomes the encoding of admin:s3cret. The colon is a separator, which is why a username may not contain one while a password may: everything after the first colon is the password. RFC 7617 requires UTF-8, which matters for non-ASCII passwords since the older btoa() approach throws on any character above U+00FF.
When should I use Bearer instead of Basic?
Bearer for anything token-based — OAuth 2.0 access tokens, JWTs, personal access tokens — which is most modern APIs. It carries a credential that can expire, be scoped to specific permissions and be revoked without changing a password. Basic sends the password itself on every single request, which cannot be scoped or revoked independently, so it survives mainly in internal services, legacy systems and simple machine-to-machine setups.
Can I decode a Bearer token to see what is inside it?
If it is a JWT, yes — the header and payload are base64url-encoded JSON and readable without any key, which is what the JWT Decoder does. Only the signature needs the secret, and only to verify authenticity rather than to read the claims. Opaque tokens that are just random strings carry no readable content; a random-looking token with two dots in it is a JWT, one without is opaque.
Is my data private when I use this tool?
Yes. This tool runs entirely in your browser using client-side JavaScript — nothing you type is transmitted to, logged by, or stored on any server. You can safely process confidential text, tokens, or code.