Where Base64 shows up: data URIs, MIME, PEM, and Basic auth

The real places binary gets wrapped in text, the size cost of doing it, and why Base64 in an auth header is not encryption.

Origins: mail could only carry text

exists because the earliest mail systems were specified for text and nothing else. A message was seven-bit characters, some byte values meant control rather than content, and gateways along the path felt free to rewrite line endings and strip the eighth bit. Anything binary sent through that survived only by accident.

The answer was to stop sending binary. Take three bytes, treat them as twenty-four bits, split into four groups of six, and map each group onto one of sixty-four characters chosen to be safe everywhere. The output is larger and completely uninteresting to any gateway, which is the point.

The standardisation arrived with in the early 1990s, and it is worth noting what MIME actually did: it did not make mail binary-capable, it made text able to carry anything. Every attachment ever sent is that decision, still being paid for in bandwidth.

Why wrap binary in text at all

Many transports were built for text, not raw bytes: email bodies, JSON and XML documents, HTTP headers, source files. Drop raw binary into any of them and a stray control byte or null can break parsing. Base64 solves this by re-expressing bytes using only safe printable characters, so binary can ride inside a text-only channel untouched. Here is where that actually happens.

The common venues

Data URIs. A data: URL embeds a small asset directly in markup or CSS, for example data:image/png;base64,iVBORw0KGgo.... The bytes of the image are Base64 right there in the attribute, saving a separate network request for tiny assets.
Email (MIME). Attachments and non-ASCII bodies are carried with Content-Transfer-Encoding: base64. MIME wraps the output into lines (classically 76 characters) so old mail servers do not choke on long lines.
. Certificates and keys are bytes wrapped in Base64 between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers, lines wrapped at 64 characters. PEM is why a certificate is a block of text you can paste into a config file.
HTTP Basic authentication. The Authorization: Basic header is the Base64 of username:password.

The size cost

Base64 is not free. Three bytes become four characters, so the encoded form is about 33% larger than the original, before any line-break overhead. That trade is usually worth it for correctness on a text channel, but it is the reason you would not Base64 a large file you could send as raw bytes. For small inline assets the convenience wins; for big payloads the overhead argues for a binary transport.

Where it turns up, and why it keeps spreading

The pattern repeats every time a text-shaped channel needs to carry bytes:

Mail attachments, the original case, still encoded the same way.
HTTP basic authentication, where the credential is Base64 - encoded, not protected, which is the single most common misreading in the field.
Tokens and certificates. PEM is Base64 with header lines; a JSON Web Token is three Base64url segments joined by dots, and the payload is readable by anyone holding the token.
Data URLs and inline images, trading size for one fewer request.
Configuration and secrets in environment variables, where a value has to be a single line of text.
Malware and phishing, for the same reason as everyone else: it moves bytes through something that only accepts text.

The URL-safe variant, and why it exists

Standard Base64 uses + and /, and both mean something else in a URL - a space in a query string, and a path separator. Base64url replaces them with - and _, and usually drops the trailing padding. It is not a different encoding, and mixing the two is a recurring defect: a token that decodes in one library and fails in another is usually this.

What it is not

It is not encryption. There is no key. Anything Base64-encoded is readable by anyone who notices, and calling an encoded value obfuscated is the obscurity mistake in miniature: nothing remains true once the encoding is removed.

It is not integrity. Base64 will happily encode a modified payload, and decode it again.

It is not a signal of malice. Seeing it in a payload tells you a channel needed text, and nothing about the content. Analysts who treat encoded content as suspicious per se end up chasing every JSON Web Token in the estate.

The practical routine

Decode it, always - the question is what the bytes are, and the encoding is not the answer to anything.
Check the variant before blaming the decoder: - and _ mean Base64url.
Watch for stacked encodings, which are usually deliberate.
Size it: about a third larger, which matters for tokens carried in every request and for anything stored per row.
If the value is a secret, remember that the encoding did nothing for it. Treat a Base64 credential exactly as you would treat the plain one.

Encoding is not encryption

The Basic auth example makes the most important point on its own. Authorization: Basic dXNlcjpwYXNz looks opaque, but dXNlcjpwYXNz is simply Base64 for user:pass, reversible by anyone, with no key involved. Base64 provides no confidentiality whatsoever. It is an encoding (a reversible change of representation), not encryption (a key-protected secret) and not hashing (a one-way fingerprint). This is why Basic auth is only safe over TLS: the transport encrypts the header, because Base64 certainly does not.

Whenever you see a long opaque-looking string, decoding it first is a cheap way to learn what it is. The Base64 tool decodes data URIs, PEM bodies, and auth headers to their raw bytes and text, entirely in your browser, so nothing you paste leaves the page.

Stacked encodings: double, triple, and beyond

Because encoding is reversible and carries no key, it is trivial to apply more than once. Base64 the output of a Base64, and you have a doubly-encoded string; do it again for triple. Each pass is legitimate on its own, and the result is still just text, which is exactly why it is a favourite obfuscation move. Attackers stack encodings (sometimes mixing Base64, URL/percent, and hex across layers) so that a payload sails past a filter or a signature that only inspects the outermost, or first-decoded, form. A (web application firewall) rule matching <script never sees it if the request carries PHNjcmlwdA== wrapped one more time.

The defence is symmetric: to understand a suspicious blob you peel the layers, decoding repeatedly until you reach plausible plaintext rather than yet another encoded string. The tell that you are not done is that a decode yields something that still looks encoded (all Base64 alphabet, or riddled with % escapes). A practical habit is to keep decoding until the output stops changing shape.

The Base64 tool supports this directly: the layers control (×1, ×2, ×3) encodes a payload through several passes, or peels several off when decoding. If you ask it to peel more layers than a payload actually has, it stops at the first layer that fails to decode and shows you exactly where, so you can see how deep the nesting really went. This is the same reason security tooling that normalizes input decodes recursively before matching: a rule that inspects only one layer is a rule an extra base64 defeats.