Base64 Encode

Base64 exists to move arbitrary bytes through channels that only reliably carry printable ASCII: an HTTP header, an email body, a JSON string, a YAML value, a data URI, a Kubernetes Secret. Sixty-four safe characters, three bytes in, four characters out. The concept is simple; the failure mode is not, and it almost always involves non-English text.

That failure mode is why this encoder does not use the browser's btoa function. btoa operates on Latin-1 and throws an InvalidCharacterError the moment it meets any character above U+00FF — so café is fine, an em dash is not, and an emoji certainly is not. Everything here goes through TextEncoder, which converts your text to UTF-8 bytes first and then encodes those bytes. Accents, CJK characters, emoji and every other part of Unicode round-trip correctly. All of it runs in a Web Worker on your machine; nothing is uploaded.

Why btoa breaks and TextEncoder does not

Base64 encodes bytes, not characters. That distinction is the whole story. Before you can encode text you must decide how to turn characters into bytes — that is, choose an encoding — and btoa makes that choice for you badly, by assuming every character is a single Latin-1 byte.

Take the string café. In UTF-8 that is five bytes, because é is 0xC3 0xA9. btoa("café") either throws or, on the legacy path, produces four bytes that decode back to something else entirely. Add a single emoji, which lives outside the Basic Multilingual Plane, and it throws unconditionally.

Encoding through TextEncoder makes the byte conversion explicit and correct: text becomes UTF-8 bytes, bytes become Base64. Decoding reverses it. Round-tripping Grüße aus München — 北京 🎉 gives back exactly what you put in, byte for byte.

If you are debugging a system that mangles accented characters through Base64, this is very often the cause: one side used a Latin-1-flavoured encoder and the other assumed UTF-8. Encoding the same string here and comparing against what your system produced will tell you immediately which side is wrong.

Standard versus URL-safe: which alphabet you need

RFC 4648 defines two alphabets. The first 62 characters are identical — A–Z, a–z, 0–9. Only the last two, and the padding, differ:

• Standard (§4) uses + and /, and pads the output to a multiple of four with =. This is what MIME, Basic authentication headers, PEM certificates and base64 on the command line produce.
• URL-safe (§5) uses - and _ instead, and this tool strips the = padding. This is the variant used by JWTs, OAuth tokens, and anything that has to survive being placed in a URL path, query string or filename.

The reason for the split is that +, / and = all mean something in a URL. A + in a query string is decoded as a space by form-decoders, / is a path separator, and = separates a parameter from its value. Put standard Base64 into a URL without escaping it and it will be corrupted somewhere downstream — usually intermittently, which makes it a miserable bug to track down.

Padding is optional for URL-safe output because the length is recoverable: a decoder can work out how many = characters to restore from the remaining length. Any correct decoder, including the companion decoder on this site, handles unpadded input.

Size overhead, and what Base64 is not

Base64 turns every 3 bytes into 4 characters, so the output is about 33% larger than the input, plus up to two padding characters. Embedding a 100 KB image as a data URI costs roughly 133 KB of HTML or CSS, and that expanded form does not compress back to the original size. It is a genuine cost, worth paying to avoid an extra HTTP request for a small icon and rarely worth paying for anything large.

And the point that has to be stated plainly: Base64 is an encoding, not encryption. It has no key, provides no confidentiality, and is reversed by anyone in one step. A Base64-encoded password in a config file, an environment variable or a Kubernetes Secret is stored in plain text with an extra step of inconvenience. Kubernetes Secrets in particular are Base64-encoded purely so that binary values fit in YAML — they are not encrypted at rest unless you configure that separately.

Where Base64 is the right answer: embedding small images or fonts as data URIs, carrying binary blobs inside JSON or XML, HTTP Basic authentication credentials, email attachments via MIME, PEM-wrapped keys and certificates, and any header value that must be pure ASCII.