Skip to main content
Yoryantra
Home/Tools
← Back to Tools

HTTP Basic Auth Header Generator

Encode a username and password into an RFC 7617 Basic Authorization header and request snippets.

Credentials

Request Output

Optional. Used only for cURL, Fetch, and Axios output.

Safety note: Basic Auth is Base64 encoded, not encrypted by itself. Avoid using real production passwords unless you need to.

Options

Keep generated Authorization headers private. Basic Auth credentials can be decoded from the header value.

Output

Generated Basic Auth output will appear here.

Basic authentication starts with exact credential bytes

HTTP Basic authentication builds a user-id:password character sequence, converts that sequence to bytes, Base64-encodes the bytes, and places the result after Basic in the Authorization field. The Base64 step is representation, not encryption.

That byte conversion matters as soon as credentials contain anything outside US-ASCII. Two clients that choose different character encodings can produce different header values from text that looks identical on screen.

The first colon has protocol meaning

RFC 7617 uses the first : to separate the user-id from the password. A user-id containing a colon is therefore invalid and is rejected here. The password may contain colons because everything after the first separator belongs to the password.

The same RFC forbids control characters in both parts. They are rejected instead of being encoded into a header that a server may interpret unpredictably.

UTF-8 is not the universal legacy default

RFC 7617 leaves the historical default character encoding undefined as long as it remains compatible with US-ASCII. A server can advertise charset="UTF-8" in its Basic challenge; when that signal is used, credential text is normalized to NFC and encoded as UTF-8.

“UTF-8 (NFC)” on this page makes that byte choice explicit. “Legacy byte mapping” exists for older systems that map U+0000 through U+00FF directly to single bytes; it should not be read as a claim about what an unknown server expects.

TLS is what protects Basic credentials in transit

Anyone who obtains a Basic header can Base64-decode the credential string. RFC 7617 does not consider the scheme secure without an external secure transport such as TLS. An http:// endpoint is therefore a meaningful warning, not a cosmetic URL preference.

A generated Authorization value should be handled like the password itself: keep it out of source control, logs, screenshots, support tickets, analytics events, and copied examples that may be shared later.

A correct header can still fail at the browser boundary

The Fetch and Axios snippets only construct the request. Cross-origin browser requests may still require a successful CORS preflight, and the target server must actually accept Basic authentication for that protection space. A syntactically correct header cannot prove either condition.

The optional JSON Accept and Content-Type fields are convenience headers for request snippets. They do not add a JSON body, and Content-Type: application/json should only be kept when the request really sends JSON.

Protocol reference

RFC 7617 defines the Basic authentication scheme, credential construction, the user-id colon restriction, control-character rules, charset behavior, and security considerations.