Text to Base64 Encoder – UTF-8 correct, with Basic auth headers

Q: Why does my output differ from what my server produced?

Usually a trailing newline. echo "secret" | base64 includes the newline echo adds; printf or echo -n does not, and the two produce visibly different strings. This page encodes precisely what is in the box, so if you paste with a trailing newline you get the first form. The other likely cause is character encoding — see the example above.

Q: Why is the output a third longer?

Every three bytes become four characters, so the ratio is 4:3 before padding. It is a property of the alphabet, not something a better implementation avoids. Compress before encoding if size matters — compressing afterwards achieves very little, since Base64 output has already lost most of its redundancy.

Q: What if my content is structured?

The typed pages check it as they encode: JSON to Base64 can minify first and keeps long identifiers exact, XML to Base64 adds the DEFLATE step SAML needs, and YAML to Base64 shapes the output for a Kubernetes Secret.

Text Input

Base64 Output

The general case

Sometimes the thing you need to encode is not a document at all. A credential for an Authorization header. A short message going into a URL. A log excerpt for a ticket system that will otherwise reflow it. A licence key. A fragment of a certificate. Base64 turns any of it into 64 characters that nothing between here and the destination will decide to reinterpret.

Type or paste on the left, take the encoded string from the right. It happens in this tab and nothing is sent anywhere — which matters when what you are encoding is a password.

The reason to use this rather than btoa() in a console comes down to one silent failure. btoa works on a "binary string", one character per byte, so it can only handle code points up to 255. Above that it throws. Below it, it does something worse: btoa('café') returns Y2Fm6Q== without complaint. Those are Latin-1 bytes. UTF-8 wants Y2Fmw6k=, and the difference does not show up until the value reaches something that decodes it properly and finds a replacement character where the é should be.

Everything here goes through TextEncoder, so the output is UTF-8 and matches what base64 at a terminal, or any server-side library, would produce for the same input.

Encoding something

Type or paste the text – Anything at all — one word, a credential, a whole log file. It is encoded exactly as given, including trailing newlines, so the result matches what base64 produces for the same content at a terminal.
Choose the alphabet – Standard for headers and APIs. URL-safe when the string goes in a URL, replacing + and / with - and _ and dropping padding. MIME wraps at 76 columns, matching openssl base64.
Take the header if one is offered – Type a single user:password line and a complete Authorization: Basic … header appears below the output, ready to copy. That is the shape RFC 7617 defines, and building it by hand is where the stray space usually creeps in.
Check the size figures – Bytes in and characters out, with the growth as a percentage. Useful before committing to a URL or a header, both of which have practical length limits that are lower than people expect.

Encoding a password does not protect it. An Authorization: Basic header is reversible by anyone who can see the request, which is why the RFC that defines it says outright that the scheme needs a secure channel underneath. Over plain HTTP you are handing out credentials to every device on the path. Encode it because the header format requires it, not because it hides anything.

Four characters, six bytes, and two different answers

The word café is five characters but six bytes in UTF-8, because é is encoded as C3 A9. Compare what this page produces with what the browser's built-in function produces for the same input. Neither throws. Only one is right, and the wrong one fails later, somewhere else, in a way that looks like a font problem.

café → base64, twice no error either way

inputOne accented character

café

# 5 characters, 6 bytes in UTF-8:
# the é is C3 A9, two bytes, not one

outputCompare the tails

# this page
Y2Fmw6k=

# btoa("café") in any console
Y2Fm6Q==

# no error. just the wrong bytes.

What people encode here

Building an Authorization header by hand

Testing an endpoint with curl or Postman, or reproducing a request from a bug report. Paste user:password and take the finished header. Worth remembering that a colon is legal in the password but not in the username, precisely because the first colon is the separator.

Putting a message somewhere hostile to punctuation

A query parameter, a filename, a database column with a narrow character set, a message queue that rewrites line endings. Encoding removes every character that anything downstream might treat as special.

Attaching a log excerpt to a ticket

Ticket systems love to reflow whitespace, convert quotes and turn URLs into links. Encoding a short excerpt means the person reading it gets exactly the characters you saw, including the trailing spaces that turn out to be the bug.

Checking what a value should have been

When something is not matching, encoding your expected value and comparing it against the one in the system is a quick way to tell a real mismatch from a copy that picked up a trailing newline.

What it does

UTF-8, always. Accents, CJK text and emoji all encode correctly rather than throwing or degrading to Latin-1.
Three alphabets. Standard, URL-safe unpadded, and MIME wrapped at 76 columns.
Basic auth headers. A single user:password line produces a complete, copyable Authorization header.
Byte-exact. Trailing newlines and whitespace are encoded rather than tidied away, so the output matches the base64 command for the same input.
Live size figures. Bytes in, characters out, and the growth — which is always about a third.
Nothing is transmitted. Passwords typed here stay in the tab.

Questions that come up

Does this hide my password?

No. Base64 has no key and is reversible by anyone — paste the output into Base64 to Text and it comes straight back. HTTP Basic uses it to make credentials safe to put in a header, not safe from being read. Everything about that scheme assumes TLS is doing the actual protecting.

Why does my output differ from what my server produced?

Usually a trailing newline. echo "secret" | base64 includes the newline echo adds; printf or echo -n does not, and the two produce visibly different strings. This page encodes precisely what is in the box, so if you paste with a trailing newline you get the first form. The other likely cause is character encoding — see the example above.

Which alphabet do I want?

Standard for a header or an API, since it is what libraries produce by default. URL-safe when the string is going into a URL — standard Base64 contains +, which a query string may legally read as a space, and that produces failures that depend on the payload and are miserable to track down. Section 5 of RFC 4648 defines the URL-safe alphabet and is a two-minute read.

Can I encode a file?

A text file, yes — use Upload. A binary file is a different job, because it has to be read as bytes rather than characters, and base64 < file.png at a terminal is the right tool. Anything this page loaded as text and re-encoded would not round-trip.

Why is the output a third longer?