Basic Auth Header Generator
Build the exact Authorization: Basic line from a username and password — or read one back — with RFC 7617 checks on this device.
—- base64 credentials
- —
- WWW-Authenticate
- —
- Charset
- —
- —
Copy as
—Press ? for shortcuts · Never stored — a username, a password and a header are credentials. This page keeps none of them between visits.
This page loads no third-party code — no ads, no trackers, no analytics. Verify in your Network tab.
Do it offline:$ curl -u 'Aladdin:open sesame' -v https://example.test/
How to use it
- Leave Direction on Build a header, or switch it to Read a header to take one you already have apart.
- Type the username. A colon is refused while you type — the server splits the credential at the first one.
- Type the password. It stays masked behind the show toggle, and colons in it are perfectly fine.
- Leave the charset on UTF-8 unless the server documents ISO-8859-1, then press Generate header (⌘/Ctrl + Enter).
- Copy the Authorization line, or pick a target and copy the curl, fetch, requests, raw-request or nginx form.
Type a username and password and get the exact Authorization line a server expects, or paste a line back to read the two values out of it. The username is checked against RFC 7617 before anything is encoded, and the byte encoding is yours to pick. Both directions run on this device: no request leaves the page, and neither field is remembered after you close it.
How it works
RFC 7617 §2 builds the credential by joining the userid, one colon and the password, then encoding those bytes as base64 — that string is the token68 that follows the word Basic. The colon is the only separator there is, so a userid may not contain one, while a password may contain as many as it likes: a reader takes everything after the first colon. Nothing is escaped or quoted on the way in.
Which bytes get encoded depends on the charset, and only non-ASCII credentials can tell the difference. RFC 7617 §2.1 registers UTF-8 as the one value a server may advertise, and a server that never learned about that parameter treats the bytes as ISO-8859-1 instead — it then reconstructs different characters from the same token and rejects a password that was typed correctly. This page shows both tokens so the mismatch is visible before you send anything.
Examples
Aladdin · open sesameAuthorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==RFC 7617 §2's own worked example. curl 8.7.1 sends the identical line for -u 'Aladdin:open sesame'.
test · 123£ (charset UTF-8)Authorization: Basic dGVzdDoxMjPCow==RFC 7617 §2.1's example: the pound sign is two UTF-8 bytes here. The same credential as ISO-8859-1 is Basic dGVzdDoxMjOj — one byte, a different token, and the tool warns before you pick the wrong one.
Authorization: Basic c3ZjOmE6Yjpjusername "svc" · password "a:b:c"Reading a header takes the whole line, a bare Basic value or just the token. The split lands at the first colon, so the two remaining colons stay inside the password.
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Spaces are kept, never trimmed
A leading or trailing space in either field is noted and encoded as typed. Trimming it quietly would hand you a token for a credential you never entered.
An empty field is legal on both sides of the colon
A userid with no password encodes as user: and a password with no userid as :secret. RFC 7617 permits both, so each draws a warning rather than a refusal — some appliances expect exactly that.
A line break is refused outright
Carriage returns, newlines, null bytes and other control characters are rejected in every field. One break inside a header value ends that field early and lets whatever follows be read as a header of its own, which is a request-splitting bug, not a typo.
Padding and casing are tolerated on paste
Reading a header accepts basic, Basic or BASIC, forgives extra spaces after the scheme, and notes a token whose trailing = characters went missing rather than refusing it. Hyphens and underscores are another matter: they belong to the URL-safe variant, not to this header.
What this page deliberately will not do
It never hashes anything, never writes a server password file and never tries the credential against a host. There is no download button either. Bearer, Digest, Negotiate and API-key schemes are other tools; so is reading userinfo out of a URL.
Common errors
Colon in the userid at position 4 — RFC 7617 §2 forbids it, because the server splits the decoded credential at the first colon and would read everything after this one as the password; remove it.- The position names the first colon in the userid as typed.
Control character '\r' in the password at position 3 — RFC 9110 §5.5 field values carry no control characters, and a CR or LF here would split the header into two; remove it.- Usually a paste out of a text editor that carried its line ending along.
The userid is 257 characters, past the 256 character limit this tool accepts — shorten it to 256 characters or fewer.- The 256 in that message is MAX_USERID_CHARS itself, printed rather than retyped.
Authentication scheme "Bearer" at position 16 — RFC 9110 §11.1 names the scheme first and this tool reads only RFC 7617 "Basic", so there is no userid ":" password inside this value; a Bearer or JWT value belongs in the JWT decoder, while Digest and Negotiate carry no recoverable password at all.- The commonest decode mistake: the wrong Authorization header got pasted.
No colon in the 7 decoded bytes at position 7 — RFC 7617 §2 defines a Basic credential as userid ":" password, so this base64 is something else; check that the whole header value was pasted.- Valid base64 that decodes to something which was never a credential.
FAQ
Is an Authorization: Basic header encrypted?
No, and RFC 7617 §4 says so plainly: the token is a reversible spelling of the credential, which anyone who reads the request can turn back into a username and password. Worse, the same value is replayed on every single request, so one capture is enough for good. Send it over TLS only, and prefer a scheme with short-lived tokens where you have the choice.
Why does my password with accents or symbols not work?
Because the two ends disagree about bytes rather than characters. If the server never sends charset="UTF-8" in its challenge it may read the credential as ISO-8859-1, and every character above 127 then arrives as something else. Switch the charset here to see the other token, and compare it with what the server accepts.
Can I read the username and password back out of a header?
Yes — set Direction to Read a header and paste the header line, the Basic value or the bare token. No key is needed to get the pair back, which is precisely why the encoding protects nothing. When the bytes are not UTF-8, both readings appear side by side.
Keyboard shortcuts
- ⌘/Ctrl + Enter
- Build the header, or decode the pasted one.
- ⌘/Ctrl + C
- Copy the Authorization line when nothing is selected and focus is in the tool.
- ⌘/Ctrl + Shift + C
- Copy that line even while a selection is active.
- ? or ⌘/Ctrl + /
- Open the shortcut help overlay.