64Base64 Encoder / Decoder

Base64 is not encryption. It is the most consequential misunderstanding about it, and it turns up in production code more often than it should — credentials Base64-encoded in a config file, a token obscured in a URL, an API key that somebody felt was hidden.

Anyone can reverse it in a second, including this page. There is no key. It is a representation, in the same way that writing a number in hexadecimal is a representation.

What it actually does is let binary data survive systems that only handle text. Sixty-four safe ASCII characters, no control codes, nothing a mail server or a JSON parser will mangle.

Where you meet it

Email attachments, because SMTP was designed for text and has carried this workaround since the eighties. Data URIs that embed a small image directly in CSS. HTTP Basic Authentication headers. Certificates and private keys pasted into environment variables. And the three segments of a JWT, joined by dots.

Why decoding fails

Almost always padding or whitespace. The encoded length must be a multiple of four, padded with equals signs, and a string copied out of a wrapped email or a terminal usually carries line breaks that need stripping first.

The other cause is Base64url, a variant that swaps plus and slash for hyphen and underscore so the result is safe inside a URL. JWTs use it. Paste one here and those characters need swapping back before it decodes cleanly.

A note on size

Encoding grows data by roughly a third. That is fine for a token and worth thinking about for an image: inlining a picture as a data URI removes one request but the file can no longer be cached separately, and it gets re-downloaded with every page that embeds it.

Text here is treated as UTF-8, which matters for accented and non-Latin characters — the same string in a different encoding produces a different result.