Basic auth generator

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from Basic auth generator

Basic Auth Generator creates an HTTP Authorization header from the username and password entered in its two fields. The value updates automatically and can be copied with the Copy button. The workspace joins the credentials with a colon, encodes that text as UTF-8 bytes and Base64, and prefixes it with Authorization: Basic. It does not authenticate against a server, check the credentials, offer a reverse-conversion panel, or generate an htpasswd entry. Base64 is reversible and provides no secrecy. Use disposable credentials for examples, and treat a real generated header as sensitive authentication material that belongs only in an appropriately protected request workflow.

Guide updated October 13, 2026

How to use this tool

1. Enter demo in Username and example in Password to reproduce the public demonstration below.
2. Read the automatically updated Authorization header. There is no conversion-direction or encoding selector in this workspace.
3. Use Copy to copy the complete displayed header. If your HTTP client has separate name and value fields, use Authorization as the name and Basic plus the encoded token as the value.
4. Test only against an endpoint you are authorized to use, over the appropriate secure connection. Review server behavior separately from the correctness of the header's representation.

SEE IT IN PRACTICE

A worked example

Username: demo
Password: example

Authorization: Basic ZGVtbzpleGFtcGxl

The encoded text is demo:example. The first colon separates the username from the password. These credentials are public demonstration values and should not be reused for an actual account.

Understand the three layers of the header

The raw credential text consists of username, a colon, and password. Base64 represents the bytes of that combined text. The Basic scheme label tells the server how to interpret the encoded value, while Authorization is the HTTP field name. Keeping those layers separate helps diagnose duplicated prefixes or an incorrectly copied field. A colon in the password occurs after the first separator and is part of the password; a colon in the username makes the intended boundary ambiguous.

Encoding and acceptance remain separate

This implementation uses UTF-8 for the text-to-Base64 step. Non-ASCII credentials require compatibility with the server's expected authentication encoding, so test that case explicitly if your system supports it. A syntactically correct header can still receive an authentication failure because of account state, server configuration, or wrong credentials. Conversely, successfully constructing a header does not activate protection on an unprotected endpoint. Verify both an authorized and an unauthorized request to the actual resource through the server's intended authentication workflow.

When this tool is useful

• Prepare a disposable HTTP Basic authentication example
• Understand the structure of an Authorization header
• Compare a client's encoded credentials with a known test value

Tips for a better result

• Do not include a colon in the username: the first colon is the separator in the combined credential string.
• Keep real Authorization values out of logs, screenshots, public snippets, and shared diagnostic files. Anyone who decodes the Base64 can recover the supplied credentials.
• Confirm how your HTTP client accepts headers. Pasting Authorization: into a field that already supplies the header name can create a malformed request.

Frequently asked questions