Which Base64 do you need?

Two almost identical alphabets, one very common source of broken tokens. Choose the variant your protocol expects.

Padding is about byte boundaries

Each Base64 character carries six bits. Three bytes fit into four characters. For one or two leftover bytes, padding fills the final four-character group. Standard padded Base64 length is 4 × ceil(byteLength / 3).

f    → Zg==
fo   → Zm8=
foo  → Zm9v

Only omit padding when the consuming protocol allows it. This site can accept unpadded input, but it still rejects invalid lengths, excess padding, misplaced padding, and nonzero unused trailing bits.

Whitespace is an explicit choice

Some formats wrap long encoded strings onto multiple lines. Standard and URL-safe presets reject whitespace. In Custom mode, “Ignore whitespace” accepts ASCII spaces, tabs, carriage returns, and line feeds. MIME has its own non-alphabet ignore rule and reports discarded characters. See the standards guide for the exact policies.

Decode bytes before interpreting text

Base64 itself has no character encoding. Text in this converter is encoded to UTF-8 first, so emoji and scripts from around the world work correctly. A decoded image, compressed file, or other binary content will not necessarily be valid UTF-8.

When decoded bytes are not displayable text, use “Save file.” The result is saved as decoded.bin with the original bytes, without rendering or executing the content.

Quick troubleshooting

• Seeing - or _? Try the Base64URL tool.
• Seeing a prefix such as data:image/png;base64,? Remove that prefix and convert only the content after the comma.
• Seeing periods in a JWT? Decode the header or payload segment separately, never the full token at once.
• Seeing mojibake after decoding? The source may use a different text encoding. Save the bytes and inspect them with a tool that supports that encoding.

Alphabet, padding, and canonical encoding rules are specified in RFC 4648, sections 3–5.