Security Tools New Tool

Free Online Basic Auth Generator and HTTP Header Decoder

Turn a username and password into an HTTP Basic authorization header, or paste a header and read the credentials back out. Choose UTF-8 or the older ISO-8859-1, get the curl and fetch forms, and see why a colon cannot appear in a username. Nothing is uploaded.

Free Forever Nothing Uploaded Both Directions Nothing Uploaded

Free Online Basic Auth Generator and HTTP Header Decoder

Advertisement Slot (Top Banner) Google AdSense Unit • Responsive Banner

Basic Auth Generator Everything happens in this tab. Nothing you paste is sent anywhere.

Header to read

Result

Direction

Credentials

Give me

For curl

Buy Us A Coffee

Enjoying WizTools123? Help keep our server infrastructure 100% free and open for everyone.

Buy Us A Coffee

Sponsored Content (Below Tool) Google AdSense Placement

Base64 Is Not Encryption, and Why That Matters Here

The one sentence that explains most Basic auth incidents.

Basic authentication sends your username and password in every request, written in base64. Base64 is a way of spelling bytes with sixty-four safe characters. It has no key, so anything that can read the header can read the password, instantly and without effort.

Anyone who sees the header has the password. Decoding it takes no secret and no tool more special than this page. That includes anything the request passes through on plain HTTP, anything that logs full headers, a screenshot in a bug report, and a terminal history file. Treat a Basic header exactly as you would treat the password written out in full, because that is what it is.

Which is why it needs TLS, every time. Over https the header is inside the encrypted connection and the scheme is reasonable. Over plain http it is a password broadcast once per request. There is no middle ground here and no configuration that makes http acceptable, which is why this page defaults the example URL to https.

It is also sent again on every single request. Unlike a login that exchanges credentials once for a session token, Basic auth attaches the password to every call, so the number of chances to leak it scales with your traffic. For a cron job hitting one internal endpoint that is fine. For a browser application it is a reason to use a token instead.

The URL form, https://user:pass@host, is worse than the header. It puts the password in a place that gets written down: browser history, server logs, referrer headers, the clipboard. Browsers have been stripping support for it for years. This page does not offer it, deliberately, and the curl form uses a header rather than a credential in the URL.

How to Build a Basic Auth Header

A few steps, and nothing is uploaded.

Choose a direction Build one takes a username and a password and gives you the header. Read one takes a header, or just the base64 out of it, and gives you back the credentials.

Type the username and password The password is masked until you press Show. A colon in the username is flagged, because the server splits on the first colon and a username containing one cannot be represented at all.

Pick the charset if you have non-ASCII characters UTF-8 is what the standard says and what you should use. ISO-8859-1 is what older servers actually read, and the two give different base64 for the same password.

Take the form you need The whole header line, just the value, the bare base64, a curl command or a fetch call. All of them are the same credential written differently.

What to Know About Basic Auth

Starting with the thing it is not.

This page cannot protect a password, because Basic auth does not. The base64 here is an encoding, not a cipher: there is no key, and anything that can see the header can read the password back in a second. Only TLS protects it in transit. If you need a credential that is safe in a log or a screenshot, Basic auth is the wrong scheme, and a token with a limited scope and a short life is the right one.

A username cannot contain a colon, and no encoding fixes that. The server decodes the base64 and splits on the first colon, so everything before it is the username. A username with a colon in it is indistinguishable from a shorter username and a password that starts with the rest. The page warns rather than producing a header that will be read as something else. A password may contain as many colons as it likes.

The charset is genuinely ambiguous, and the two choices give different results. RFC 7617 says UTF-8 and lets a server advertise it, but plenty of older servers decode the bytes as ISO-8859-1, so a password with an accent or any non-Latin character produces a header that one accepts and the other rejects. Both are offered here. If a correct looking password keeps failing against an old server, this is usually why.

Nothing is remembered, and nothing is checked. There is no history and no saved setup on this page, deliberately, so a password never reaches browser storage. The page also does not contact the server in your URL: the curl and fetch forms are text for you to run, and whether the credentials actually work is something only that server can tell you.

Key Features & Capabilities

What this tool does, and what it deliberately does not.

Both directions Build a header from credentials, or read credentials out of a header.

Charset handled UTF-8 or ISO-8859-1, with the difference shown rather than guessed at.

curl and fetch The ready to paste forms, using a header rather than credentials in the URL.

The colon rule A colon in the username is flagged, because the server will split on it.

Password masked Hidden until you press Show, so it stays out of a screen share.

Nothing remembered No history and no saved setups. A password never reaches browser storage.

About HTTP Basic Authentication

HTTP Basic authentication is the oldest and simplest way to put a username and password on a request. The client joins them with a colon, encodes the result as base64, and sends the line Authorization: Basic followed by that string. There is nothing else to it, which is both why it is still everywhere and why it is so often used in places it does not belong.

The useful thing a page like this can do is not the base64, which is trivial, but the two details that actually catch people. The first is the colon: the server splits on the first one, so a username containing a colon cannot be expressed, and a header built from one will be silently misread. The second is the charset, where the standard says UTF-8, many older servers read ISO-8859-1, and a password with an accent in it produces two different headers depending on which you believe. Both are surfaced here rather than assumed.

The decode direction exists because that is the half people reach for under pressure. A request is failing, a log line has an Authorization header in it, and the question is which account it was using. Pasting the whole header works, pasting just the base64 works, and the page tells you when the bytes are not valid UTF-8 and shows you the ISO-8859-1 reading instead, which is the usual sign of a client on the other side of the charset question.

What the page says plainly, and keeps saying, is that base64 is not encryption. There is no key involved, so a Basic header is the password written in a slightly less readable alphabet. Over TLS that is acceptable. In a log file, a screenshot, a URL or a plain HTTP request it is a password leak that merely looks technical. Saying so is more useful than producing the header quietly and leaving the impression that something has been protected.

Frequently Asked Questions

Headers, charsets, colons and what base64 protects.

No. It is base64, which is an encoding with no key, so anyone who sees the header can read the username and password immediately. Only the TLS connection protects it, which is why Basic auth over plain http is the same as sending the password in clear text.

Because the server decodes the base64 and splits on the first colon to separate the username from the password. A username with a colon in it would be read as a shorter username and a different password. The password itself may contain any number of colons, since only the first one matters.

UTF-8, unless something tells you otherwise. RFC 7617 specifies it and lets a server advertise that it expects it. ISO-8859-1 is here because many older servers decode the bytes that way, and for a password with a non-ASCII character the two produce different base64, which is a common reason a correct password is rejected.

You can write https://user:pass@host and some tools still accept it, but it is a bad idea and browsers have been removing support. A password in a URL ends up in history, logs and referrer headers. This page gives you the header form for that reason, including in the curl command.

No. The encoding and decoding happen in the page, and the curl and fetch forms are text for you to run yourself, not requests this page makes. There is also no history and no saved setup here, so nothing is written to browser storage.