Base64, decoded

Base64 exists to move arbitrary bytes through channels that only accept text: e-mail bodies, JSON strings, HTTP headers, XML documents, URLs. It takes three bytes at a time, splits those 24 bits into four six-bit groups, and writes each group as one of 64 printable characters. Three bytes in, four characters out — which is why base64 output is always about a third larger than what went in, and why base64 payloads are so often compressed first.

It is not encryption. There is no key, and no secret is needed to reverse it. A base64 string in a cookie, a URL, or a config file is visible data, and should be treated that way by everyone who handles it.

The two alphabets

A string that contains both +/ and -_ is not base64 of either kind — that mixture is a reliable "this is something else" signal, and the decoder here rejects it outright rather than guessing.

Recognising it

There is no syntactic test. password is a perfectly valid base64 string: eight characters from the alphabet, length divisible by four. It decodes to six bytes of noise. So does every other lowercase word of the right length. This is exactly why naïve "auto-detect base64" tools produce nonsense — they check the characters and stop.

The signals that actually work, in order of strength:

• Decode it and look. Real base64 produces text, a recognisable file signature, or structured data. 1f 8b is gzip, PK is a zip, %PDF is a PDF, { is JSON. Noise means it was not base64.
• Trailing =. Padding is a deliberate act by an encoder; no English word ends in one. It also tells you the input length mod 3.
• Mixed case with digits, no spaces, length a multiple of four. Weak on its own, useful in combination.
• Context. The header is called Authorization: Basic, the field is called state, the value came out of a data: URI.

Where it hides things

• HTTP Basic authentication. Authorization: Basic dXNlcjpwYXNzd29yZA== is user:password — the credentials are not obscured in any meaningful sense, which is why Basic auth over plaintext HTTP is credential disclosure.
• JWTs. Three base64url segments separated by dots. The claims are readable by everyone who touches the token; the signature only stops them being changed. See the JWT page.
• SAML. Assertions are base64, and in the HTTP-Redirect binding they are raw-deflate compressed underneath — an encoding that cannot be detected by inspection, so you have to ask for it.
• data: URIs. data:text/html;base64,… carries a whole document, with its own origin. That is why data: in a CSP script-src is close to 'unsafe-inline' — see the CSP builder.
• Exfiltration and droppers. Base64 turns binary into something that passes a content filter looking for executables, and into something that fits in a DNS label or a URL parameter.

Nesting

Base64 is rarely the last layer. The shape that turns up over and over is base64 of gzip of JSON: something was too big for a cookie or a query parameter, so it was compressed, and compression produces bytes, so it was encoded. The decoder unwraps all three without being told, because each layer leaves evidence the next step can check — gzip's 1f 8b magic, then JSON's opening brace.

Double base64 is also common, and is usually a bug rather than an intention: two systems each helpfully encoding the same field. If a decoded value still looks like base64, it probably is.