Base64 decode

Consider what people paste into a Base64 decoder. A JWT, to see whose token it is. A value out of a Kubernetes secret, which is a password written in a way that looks like it is not. A Basic authorisation header lifted from a request log. A webhook payload from production. Three of those four are credentials, and the fourth is usually customer data.

A decoder that works on a server has seen every one of them, and has them in its access logs whether or not anybody intended to keep them. That is not a theoretical risk — it is why this class of site is blocked at the proxy in a lot of places. This page does the arithmetic in your tab, and the network panel is how you check rather than a promise you have to take.

A JSON Web Token is three URL-safe Base64 segments separated by dots. Paste the middle one here and you get the payload: the claims, the subject, the expiry as a Unix timestamp. Paste the first and you get the header, which names the signing algorithm. Both are readable by anyone holding the token, which surprises people and should not — a JWT is signed, not encrypted.

What decoding cannot tell you is whether the token is valid. The third segment is a signature over the first two, and checking it needs the key. So this will show you that a token claims to expire next Tuesday; it will not show you whether somebody edited that claim. If you are relying on the contents, verify the signature somewhere that has the secret.

Base64 encodes bytes, and bytes are not always characters. Decode the start of a PNG and the result is a signature, a chunk length and binary — a string of replacement characters at best, and mojibake at worst. Most decoders hand that over anyway, which leaves you staring at nonsense with no idea whether the input was wrong or the content simply is not text.

This one says so instead. The decoder is strict about UTF-8, so bytes that do not form valid text are reported as exactly that, with the byte count, rather than being quietly replaced with U+FFFD. "Valid Base64 of a file" and "not Base64 at all" are two different problems and they get two different answers.

Padding is optional here. A JWT segment carries none, because `=` is reserved in a URL, and a decoder that requires it rejects every real token — which is a specification being upheld against the entire population of things it describes. Whitespace and line breaks are stripped, because a PEM block copied out of a terminal is wrapped at 64 characters and nobody is going to rejoin it by hand.

Both alphabets are accepted without asking which you have. Standard Base64 ends in `+` and `/`; the URL-safe variant uses `-` and `_`. They cannot be confused for one another, so the decoder simply translates both, and there is no setting to get wrong.

The most common cause is a copy that took something extra with it: a trailing dot, a quotation mark from the JSON it was in, or the `data:image/png;base64,` prefix from a data URI, which is metadata rather than payload. Base64 uses only A–Z, a–z, 0–9 and two symbols, so anything else is a clue about where the copy went wrong.

The second most common is a partial copy. Terminals wrap and selections stop early, and Base64 gives no hint that it is truncated — it decodes the part it has and produces text that stops mid-word, or fails on a length that is no longer a multiple of four. If the output ends somewhere strange, check the input for the same.