Basic Auth Header Generator
Turn a username and password into an HTTP Basic Authorization header, Base64 token, and curl example - or decode a Basic token back to credentials. All in your browser.
- Free, no account
- No watermark
- No usage limit
About the Basic Auth Generator
Type a username and password and you get the exact Authorization: Basic <token> header, the raw Base64 token, and a ready-to-run curl line, all three at once, each with its own copy button. It runs in your browser and nothing leaves the page. Then there's the Decode tab. Paste any Basic token and it reads the username and password straight back out.
Which is the whole reason this page exists. Basic Auth feels like security because the token looks scrambled, but it isn't. That blob is just username:password run through Base64, and Base64 reverses in one step, no key, no cracking. The Decode tab lets you prove it in about a second, paste a token, read the password. Once you've watched how trivial that is, you stop treating Basic Auth as protection and start treating HTTPS as the only thing standing between your credentials and anyone watching the wire.
Most basic-auth tools stop at one box in one direction. Type creds, copy a token, done. Two things here go past that. First, decode takes a whole header line, not just a bare token, so you can paste Authorization: Basic YWRtaW46MTIzNA== copied straight out of a config file or someone's curl command and it strips the Authorization: Basic part for you before decoding. Second, it gets non-ASCII right where a lot of tools quietly break it. A password like café, or one with a £ in it, is encoded as UTF-8 first the way a correct client does, so it round-trips instead of arriving at the server as mangled bytes.
How to use
- Pick Generate or Decode with the buttons up top. Generate turns credentials into a header, Decode reads a token back into credentials.
- Type or paste a username and password in Generate mode. The header, Base64 token, and curl line fill in as you type. No submit button.
- Reveal the password if you need to check it. The field is masked by default. Hit Show to see it, Hide to cover it again, useful when you're copying from a manager or hunting a typo.
- Copy whatever form you need with the button beside it, the bare token, the full
Authorization: Basic ...header, or the curl one-liner. - To decode, paste the token or header. Drop in a raw Base64 token,
Basic <token>, or the entireAuthorization: Basic ...line. It strips the prefix, decodes, splits on the first colon, and shows the username and password apart. - Clear empties the fields. Nothing is saved anywhere, so that's the whole cleanup.
Why HTTPS is the only thing protecting Basic Auth
Go back to that token. YWRtaW46MTIzNA== decodes to admin:1234, and you don't need this tool for it, any Base64 decoder on the planet does the same. So the token protects nothing on its own. Whoever can see it can read the credentials, full stop.
That leaves exactly one thing guarding a Basic Auth request: the encrypted tunnel it rides in. Over HTTPS, TLS wraps the entire connection, header and all, so a sniffer sees ciphertext and nothing else. Over plain HTTP the same header crosses the network in a form anyone on the path can grab and reuse. Basic Auth over HTTP is cleartext credentials with an extra decoding step, that's all it is.
A few consequences fall out of that. The credentials ride on every request to that realm, login and every click after. That's a lot of trips across the wire, and each one is another chance for an attacker to grab them, and there is no real way to log out afterwards. The browser caches the header and keeps resending it until you fully close it, and a captured header replays indefinitely because Basic Auth has no expiry and no revoke. Changing the password is the only way to kill a leaked one.
None of that makes Basic Auth useless, it just means the job it's good for is a narrow one. It's genuinely fine for gating a staging site that already sits behind HTTPS, for calling an old API that accepts nothing else, or for a throwaway test against your own endpoint. Where it falls apart is a public app with real users, anything guarding money or personal data, or any case where you need to cut off one person without resetting the password for everyone. Those want an API key, a session cookie, or a signed token that expires on its own. If you're not sure Basic Auth is strong enough for what you're building, it probably isn't. Reach for a token.
The .htpasswd mix-up
If you're locking down an Apache directory with .htaccess, it points at an .htpasswd file, and this is where people paste the wrong thing. The Base64 token this tool generates does not go in .htpasswd at all.
The token is what the browser sends over the wire. .htpasswd is what the server stores to check against, and it holds a hashed password (bcrypt, or Apache's own MD5 variant, or SHA-1), never the Base64 blob, and the difference is deliberate. If someone walks off with your .htpasswd, the stored hash still doesn't reveal the passwords, while a Base64 token would give them up immediately.
So build that file with Apache's htpasswd command (htpasswd -c .htpasswd admin), which does the hashing for you. This tool covers the client side, the header you send. The server-side file plays by different rules, and swapping one for the other is a classic source of a login that mysteriously never works.
Frequently asked questions
Can my password contain a colon?
Yes. Basic Auth joins the two as username:password and the server splits on the first colon, so everything after that first colon counts as the password. A password like p:ss:word is completely valid. The username can't contain a colon though, because that would break the split. Decoding here follows the same first-colon rule, so a colon-heavy password comes back intact.
Why does my browser pop up a login box for Basic Auth?
That box is the challenge. When a server protects a URL, it answers an un-authenticated request with 401 Unauthorized plus a WWW-Authenticate: Basic realm="..." header. The browser turns that header into the login prompt. Once you enter credentials it caches them for that realm and stops asking, until you hit a URL in a different realm or close the browser, since there's no logout to reset it.
My token decodes to garbage or throws an error. What's wrong?
Three usual suspects. A stray space or newline snuck in when you copied it, so trim the ends. The = padding at the end got dropped, those signs are part of the token, keep them. Or the string isn't actually a Basic token, if the decoded value has no colon in it, it wasn't username:password to begin with, and the tool tells you so instead of guessing.
Isn't `curl -u user:pass` easier than pasting a header?
For a quick call, sure. curl -u admin:1234 https://example.com/ builds the identical Authorization: Basic header behind the scenes. But -u admin:1234 sitting in a script leaves the password in your shell history and process list where anyone on the box can read it. Generating the explicit header and passing it another way keeps the raw password out of those logs. You also need the literal header form when you're pasting into Postman, an HTTP client, or a config that wants a header string, not a user and pass pair.
Does Basic Auth work for API calls, not just browser logins?
Yes, and it's common on older or internal REST APIs. Instead of a login page you attach Authorization: Basic <token> to every request yourself. Payment gateways, CI servers, and monitoring endpoints still accept it. The catch is the same one as always, every request carries the credentials, so keep it on HTTPS and don't reuse a production password you'd hate to see logged.
Is there a size limit on the username or password?
The Basic Auth scheme itself sets no limit. The practical ceiling is the server's max header size, since the token travels in a request header. Many servers cap total headers around 8KB by default, far more than any normal credential needs. If a long token gets a 400 or 431 back, the header size limit is the thing to check.
What's `Proxy-Authorization`, and is it the same token?
It's the sibling header HTTP proxies use to authenticate you to the proxy itself, separate from the site you're actually reaching. The token format is identical, Base64 of username:password, so you can generate it here and just swap the header name from Authorization to Proxy-Authorization.
Are my credentials sent anywhere when I use this tool?
No. The encoding and decoding both happen locally in your browser, there's no server in the calculation and nothing is uploaded, logged, or saved. Even so, treat any web page as a web page. Prefer test credentials over real production ones, and clear the field when you're finished.