Base64 Decoder
Decoding reverses the transform: four Base64 characters become three bytes, and those bytes are read back as UTF-8 text.
This page opens with the decoder selected, which is the mode you want when you have pulled an opaque-looking string out of a token, a config file or an HTTP header.
Recognising Base64 in the wild
Base64 strings are drawn from A-Z, a-z, 0-9, + and /, and their length is a multiple of four once padding is counted. A string ending in one or two equals signs is a strong signal.
If it contains - or _ instead of + and /, it is base64url - the URL-safe variant used by JWTs and often written without padding. It decodes to the same bytes.
Why a decode fails
- Wrong length - characters were lost in transit, or a line was truncated on copy.
- Whitespace and newlines - Base64 in emails and PEM files is line-wrapped, and the breaks must be stripped before decoding.
- It is base64url with padding stripped, and the decoder expects standard Base64.
- It decoded fine, but the bytes were never text. Compressed data and images produce garbage when read as UTF-8, and that is expected rather than an error.
What you get back is untrusted input
Decoding a value from a token or a request body gives you exactly what the sender put in. It has not been validated by the round trip, and a decoded string can still contain zero-width characters, control codes or markup. Treat it as you would any other input from outside your system.