How HTTP Basic authentication works on the wire
Basic authentication, defined in RFC 7617, is the simplest scheme in the HTTP authentication framework. The client joins the username and the password with a single colon, encodes the resulting byte string with base64, and sends it in one request header. For the username admin and the password s3cret, the string admin:s3cret encodes to YWRtaW46czNjcmV0, and the request carries Authorization: Basic YWRtaW46czNjcmV0.
A server that wants credentials answers an unauthenticated request with 401 Unauthorized and a WWW-Authenticate: Basic realm="Staging API" header. The realm is a label for the protected area, which browsers show in their native credential prompt and use to decide which stored credentials to reuse. Once a browser has credentials for a realm it usually resends them automatically on later requests to the same scope, which is why there is no server-side session and no logout endpoint in Basic auth.
This tool builds that header locally from whatever you type. It also emits the curl equivalent, curl -u "admin:s3cret" https://api.example.com/me, which produces the identical header. Nothing is sent anywhere: the encoding is done in the page with TextEncoder and btoa.
Base64 is encoding, not encryption
This is the single most important thing to understand about Basic auth. Base64 is a reversible transformation that maps arbitrary bytes onto a 64-character alphabet so they survive text-only transports. It uses no key, keeps no secret and provides no integrity check. Anyone who sees YWRtaW46czNjcmV0 can run it back through a base64 decoder and read admin:s3cret in a second. Treat a Basic auth header as the password written in plain sight.
The consequence is that Basic auth is only acceptable over TLS. On plain HTTP the header travels in the clear, so every intermediate proxy, every shared network and every request log holds the actual password. Over HTTPS the header is encrypted along with the rest of the request, which is what makes the scheme usable at all. Never send a Basic auth header to an http:// URL you care about.
Even over HTTPS the password keeps leaking into places you did not plan for. Full request URLs and headers routinely land in access logs, error trackers, shell history, CI job output and screen recordings. Because the credential is long-lived and unrotated by default, one leaked header stays valid until somebody changes the password by hand.
Non-ASCII passwords and the colon rule
RFC 7617 does not fully define character encoding for legacy reasons, which historically made accented and non-Latin passwords behave differently between clients. The modern answer is UTF-8: a server can advertise WWW-Authenticate: Basic realm="x", charset="UTF-8" and clients should encode the credential bytes as UTF-8 before base64. This tool encodes with TextEncoder, which is UTF-8, so a password such as pa55word with an accented character produces the bytes a UTF-8 aware server expects.
The username may not contain a colon. The server splits the decoded string at the first colon it finds, so everything after that first colon is treated as the password. A password may contain colons freely, because no further splitting happens. A username with a colon would be silently misparsed, which is a good reason to keep usernames to simple ASCII identifiers.
Base64 output grows by roughly a third and pads with = characters, so a 24-byte credential becomes a 32-character token. Some proxies and embedded servers cap header size, which matters if you generate very long random passwords.
When Basic auth is a reasonable choice, and when it is not
Basic auth is defensible for a staging environment behind TLS, an internal metrics endpoint, a webhook receiver that only your own service calls, or a quick reverse-proxy gate in front of a site that is not ready for public traffic. In those cases its lack of moving parts is the point: no token store, no refresh flow, no session cookie.
It is a poor fit for anything user-facing. There is no way to log out reliably, no expiry, no scoping and no way to revoke one client without changing the password for everyone who holds it. It offers no protection against a stolen credential being replayed, and it gives you no audit trail beyond an IP address. For end-user login use a session cookie with proper flags or an OAuth-based token flow; for machine-to-machine use a scoped API key or a short-lived bearer token you can rotate.
If you do use it, give every client its own username so you can revoke one at a time, generate the password randomly rather than choosing one, and put the credential in a secret manager rather than in a committed config file or a Dockerfile. Rotating a Basic credential is entirely manual, so decide in advance who does it and when.