Base64 Decode

How Base64 Decoding Works

Decoding runs the encoding pipeline backwards. Each Base64 character is looked up in the 64 character alphabet to recover the 6 bit value it represents. Four of those values are concatenated into a 24 bit block, and that block is sliced back into three 8 bit bytes. Padding at the end tells the decoder how many of those bytes are real.

1. Strip any whitespace and line breaks, which carry no meaning.
2. Convert each character to its index in the alphabet, 0 to 63.
3. Join four indexes into a single 24 bit block.
4. Split the block into three bytes, most significant bits first.
5. Discard one byte for every trailing equals sign, then interpret the bytes.

Worked Example: Decoding "SGVsbG8="

This string has eight characters, one of which is padding, so it decodes to five bytes rather than six.

Why Decoding Fails

Base64 is strict about shape, and most failures come from a handful of causes:

• Invalid characters. Anything outside A-Z, a-z, 0-9, plus, slash, and equals is rejected. Copying from a chat client that inserts smart quotes or a zero width space is a frequent culprit.
• Wrong length. Standard Base64 length must be a multiple of four once padding is included. A truncated copy and paste is the usual cause.
• Missing padding. Many producers strip trailing equals signs. Add them back until the length divides by four.
• URL-safe input in a standard decoder. Dashes and underscores are not in the standard alphabet and must be translated first.
• Double encoding. If the decoded output is itself another valid looking Base64 string, the value was probably encoded twice.

Standard Base64 vs URL-Safe Base64

Standard Base64 uses plus and slash for indexes 62 and 63. Both are awkward in a URL: slash is a path separator and plus means a space in form encoded data. RFC 4648 section 5 therefore defines a URL and filename safe variant.

JSON Web Tokens always use the URL-safe form without padding, which is why a JWT segment pasted into a strict standard decoder often fails. Convert dash to plus, underscore to slash, and pad the length up to a multiple of four before decoding.

Is the Decoded Output Text or Binary?

Base64 carries no type information, so the decoder cannot tell you what the bytes mean. If the result renders as readable words or valid JSON, it was text, almost always UTF-8. If you see replacement characters, control codes, or unprintable symbols, the payload was binary. A short signature at the start is often enough to identify it: bytes 89 50 4E 47 mean PNG, FF D8 FF means JPEG, 25 50 44 46 means PDF, and 50 4B 03 04 means a ZIP archive (which includes .docx and .xlsx files).

The Base64 Alphabet

Every 6 bit group produces a value between 0 and 63, and that value is looked up in the table below. RFC 4648 fixes this ordering: uppercase letters first, then lowercase, then digits, then the plus and slash characters. The padding character (=) is not part of the alphabet, it only marks the end of an incomplete group.