Turn a user name and password into Authorization: Basic, with curl and fetch snippets you can paste as they are
Paste the value of an Authorization: Basic ... header to recover the user name and password. The leading Basic is optional.
Join the user name and password with :, Base64-encode the result and place it after Basic . For user and pass, user:pass encodes to dXNlcjpwYXNz, so the header reads Authorization: Basic dXNlcjpwYXNz. A user name cannot contain a colon, because the first colon is treated as the separator; a colon inside the password is fine.
A server answers a protected resource with 401 and WWW-Authenticate: Basic realm="...", and the client repeats the request with an Authorization header. Scripts and tools may send the header immediately instead of waiting for the 401. The realm only labels which credentials belong where; it does not affect whether authentication succeeds.
This tool encodes as UTF-8. RFC 7617 lets a server advertise charset="UTF-8", but implementations differ in how they treat non-ASCII credentials. If a password with accents or symbols fails to authenticate, test with an ASCII-only value first to isolate the cause.
| Where | Form |
|---|---|
| HTTP request | Authorization: Basic dXNlcjpwYXNz |
| curl, explicit header | curl -H 'Authorization: Basic dXNlcjpwYXNz' https://example.com/api |
| curl, -u form | curl -u 'user:pass' https://example.com/api |
| fetch, JavaScript | fetch(url, { headers: { Authorization: 'Basic dXNlcjpwYXNz' } }) |
The -u form makes curl build the same header internally. Either way the credentials can end up in shell history or CI logs, so keep long-lived values in environment variables or a secret manager.
Join the user name and password with a colon, Base64-encode that string, and prefix it with "Basic ". For user and pass, user:pass encodes to dXNlcjpwYXNz, giving Authorization: Basic dXNlcjpwYXNz. This is encoding, not encryption.
No. Base64 is reversible by anyone and provides no secrecy. Basic credentials travel in an effectively plaintext form, so they can be read by anyone observing a non-HTTPS connection. Always require TLS when using Basic authentication.
This tool encodes as UTF-8. RFC 7617 lets a server advertise charset="UTF-8", but server implementations differ in how they interpret non-ASCII credentials. A user name cannot contain a colon, because the first colon is the separator.