Base64 Decoder

A Base64 string encountered in the wild might be standard Base64 — from an email attachment, a data URI, a config file — or Base64URL, most commonly from one of the three dot-separated segments of a JWT. Since the two variants differ only in three characters, a decoder that insists on exactly one form forces you to manually swap `-` for `+` and `_` for `/` before it will accept a token segment, which is a fiddly extra step for something that should be a single paste. Accepting both variants means a JWT payload segment can be pasted directly, without first knowing or caring which variant of Base64 it happens to be.

Not everything encoded in Base64 is text to begin with — images, encryption keys, and other binary data are also commonly Base64-encoded for exactly the same text-safety reasons. Decoding one of those produces raw bytes that display as garbled, unreadable characters when interpreted as text, which is expected rather than a sign the decoding failed: the operation reversed the encoding correctly, but the underlying bytes were never meant to be read as UTF-8 text in the first place.

Pasting an unfamiliar Base64-looking string here and checking whether it decodes to something legible is a fast first step when investigating what a piece of data actually is — a config value, a cookie, a token fragment found somewhere unexpected. A string that decodes cleanly to readable JSON or plain text confirms it really is Base64-encoded data; one that produces garbage on decoding is either not Base64 at all, or is Base64-encoded binary data rather than text, either of which narrows down what to investigate next.