Base64 Encoder and Decoder

What it is for

Base64 solves one problem: you have arbitrary bytes, and a channel that will only carry printable text. Email headers, JSON string fields, URLs, HTML attributes, and a good deal of older infrastructure all fall over on raw binary. Base64 maps every three bytes onto four characters drawn from a 64-symbol alphabet that survives all of them.

That is the whole purpose. It is not compression — the output is a third larger. It is not encryption — there is no key. It is a transport encoding, and every property people mistakenly attribute to it comes from mistaking “I cannot read this” for “this is protected”.

Where you will meet it

• JWTs. All three segments, in the URL-safe alphabet with padding stripped.
• HTTP Basic auth. Authorization: Basic is just user:password Base64-encoded — which is exactly why Basic auth over plain HTTP is equivalent to sending the password in the clear.
• Data URIs. data:image/png;base64,... embeds a file directly in HTML or CSS.
• PEM certificates and keys. The lines between -----BEGIN----- and -----END----- are Base64-encoded DER.
• Email attachments. SMTP is a text protocol; MIME uses Base64 to carry anything that is not.

The Unicode trap

The browser gives you btoa and atob, and they are a trap. Both operate on bytes represented as a string, so btoa throws on any character above U+00FF. Try it on an emoji and you get InvalidCharacterError.

The fix is to convert to UTF-8 bytes first, which is what this page does:

// Encode any string safely
const bytes = new TextEncoder().encode(text);
const b64 = btoa(String.fromCharCode(...bytes));

// Decode back
const binary = atob(b64);
const out = new TextDecoder().decode(
  Uint8Array.from(binary, c => c.charCodeAt(0))
);

One caveat on the encode line: spreading a large array into String.fromCharCode overflows the call stack somewhere around a hundred thousand elements. For anything large, loop in chunks — this page does, which is why it handles a multi-megabyte paste without falling over.

The two alphabets

The padding is the part that causes trouble. Its only job is to make the length a multiple of four, and a decoder can always work out how much is missing — so the URL-safe variant drops it. Strict decoders then reject the result, which is why a JWT segment pasted into another tool so often fails. The decoder here restores the padding itself.

Where it is misused

Because Base64 is unreadable at a glance, it gets used as though it were a secret. It is worth naming the specific patterns:

• Base64 as password storage. This is plaintext with a costume on. Passwords need a slow one-way hash — bcrypt, scrypt, Argon2.
• Base64 in a JWT payload as though it were private. The payload is readable by anyone holding the token, including the user. Never put anything in it you would not show them.
• Base64 to sneak data past a filter. It works, briefly, and every scanner worth having decodes it anyway.

The rule that covers all three: if the security of something depends on the reader not decoding it, it has no security.

Related

The JWT decoder splits a token and parses both segments in one step. For escaping text going into a URL rather than encoding bytes, percent-encoding is the different thing you probably want. And if what you decoded turns out to be JSON, the formatter will lay it out.