Base64 Decoder

How decoding works, and why some strings are impossible

Decoding reverses the encoding step for step: each group of four characters maps back to three bytes through the same 64-symbol table. The arithmetic is not what typically goes wrong. What goes wrong is the input not being a valid encoding in the first place.

A Base64 string of valid length always has a character count that is a multiple of four, or one that leaves a remainder of two or three which padding then tops up. A remainder of one is structurally impossible: no sequence of input bytes can produce it, because one leftover character carries only six bits and a byte needs eight.

In practice a length error almost always means the value was truncated. Copying a long token out of a terminal, a log viewer or a chat window frequently clips it, and the missing characters come off the end. A length that is not a multiple of four, with no padding to explain it, is the signature of that.

The other routine failure is a character from outside the alphabet. A space in the middle of the string, a smart quote substituted by a word processor, or a stray newline in the wrong place will all cause a strict decoder to reject the whole input rather than decode the part it can. This decoder normalises the common cases — whitespace, both alphabets, missing padding — and reports what it did, so an error here means something genuinely unexpected is in the string.

Text or bytes: why the hex view matters

Base64 carries bytes, and bytes are not necessarily text. The distinction matters because a decoder that assumes text will silently corrupt binary data.

UTF-8 is a strict encoding with defined rules: specific byte sequences are valid, and others are not. When a decoder finds bytes that do not form valid UTF-8, there are two honest options and one dishonest one. It can refuse, which is unhelpful when the data is legitimately binary. It can show a hex dump, which is truthful. Or it can substitute replacement characters, which is what most tools do and which renders the output useless — you cannot tell a real replacement character in the data from one the decoder invented.

This tool takes the hex route and tells you it has. Common cases where you will see it:

• A Base64-encoded image or audio fragment — binary by definition, no text representation exists.
• A cryptographic key or certificate across a boundary that split a DER structure.
• Compressed data, such as gzip output stored in a database column.
• Encrypted ciphertext — which is the important one to recognise, because it looks like corruption but is working as designed.
• A truncated UTF-8 sequence, where the encoding was cut mid-character. Here the hex dump reveals the problem rather than hiding it.

Reading the hex dump is worth a moment: a leading 1f 8b is gzip, 50 4b 03 04 is a ZIP archive, 89 50 4e 47 is a PNG, ff d8 ff is a JPEG. Recognising a magic number tells you what the payload actually is, which is often the whole question you came with.

Variants this decoder accepts

Input is normalised before decoding, so you do not have to know which variant you have. Specifically:

• Standard and URL-safe alphabets. - and _ are treated identically to + and /. A JWT segment pastes in and decodes without editing.
• Missing padding. A string whose length is not a multiple of four is padded back to one before decoding, which is what makes unpadded URL-safe values work.
• Embedded whitespace. Newlines, tabs and spaces are stripped. A PEM block or a MIME attachment body can be pasted wholesale, headers included, and the base64 lines will still decode.
• Case sensitivity preserved. The alphabet is case-sensitive by definition — A and a are different symbols — so no case folding is applied, and none should be.

Because the tool reports which form it detected, you can use it to answer the reverse question: if you are unsure whether a string is standard or URL-safe, decoding it here and reading the detected form settles it.

Decoding is not decryption, and not decompression

Two confusions are common enough to address directly, because both lead people to conclude that a tool is broken when it is working correctly.

Base64 is not a cipher. If the bytes you decode are ciphertext, you get the ciphertext bytes back. They will look like noise, and they will be exactly the bytes the encrypting party produced. Any tool that claims to decrypt Base64 without asking for a key is simply decoding, whatever its interface suggests. Real decryption needs the algorithm and the key, and the output of an incorrect key is indistinguishable from random bytes.

Base64 is not compression. A common pattern is to gzip a payload and then Base64 the result for transport. Decoding that with a Base64 tool yields the gzip stream, not the original text. You will see the hex signature 1f 8b at the start, which is your cue that a second step is required. That is expected behaviour, not a failure.

The general principle is that encoding layers stack, and each must be removed in reverse order of application. Base64 is usually the outermost layer because it is what makes the data safe to transport, so decoding it first is normally right — but it is rarely the only step.

Working with JWT segments

A JWT is three Base64 segments joined by dots, and you can decode each one here. The header and payload are base64url-encoded JSON, so decoding either gives you a JSON document; the signature is raw bytes and will usually come back as a hex dump.

Doing it this way is instructive the first time, because it demonstrates the point that a JWT payload is readable by anyone. After that, the JWT Decoder is the better tool: it splits the token for you, formats the JSON, labels the header and payload, and explains the registered claims rather than leaving you to look up what aud means.

One practical note if you are decoding segments by hand: paste only the segment, without the surrounding dots, since a stray dot is not a valid Base64 character and will be rejected.