The 64-character alphabet
Base64's name is literal: it uses an alphabet of exactly 64 characters — uppercase A–Z, lowercase a–z, digits 0–9, plus + and /. Every output string is built solely from these, which is why Base64 survives systems that choke on binary data or special symbols.
Each character represents 6 bits of data. That is the whole trick: 6 bits fit neatly into a printable character, so any byte sequence can be rewritten as a string of safe characters with zero ambiguity.
How 3 bytes become 4 characters
Encoding works in groups: every 3 input bytes (24 bits) are split into four 6-bit chunks, each mapped to one alphabet character. Three bytes in, four characters out — which is exactly why Base64 output is always about 33% larger than the input.
When the input length is not a multiple of 3, padding fills the gap: one = if one byte is missing from the final group, two == if two are missing. The padding tells the decoder precisely how many real bytes the last group holds.
Variants: URL-safe and MIME
Standard Base64's + and / cause trouble in URLs, where they have special meanings. The URL-safe variant swaps them for - and _, and often drops the padding — this is the base64url form you see inside JWT tokens.
The MIME variant, used in email, is standard Base64 with line breaks inserted every 76 characters, because old mail systems disliked very long lines. Same data, just wrapped for transport.
Choosing the right variant
For configs, headers, and JSON: standard Base64. For URLs, filenames, or JWTs: the URL-safe variant. For email attachments: MIME with line wrapping. Mixing them up is a classic bug — a standard decoder will reject - and _ as invalid characters.
When in doubt, check what the receiving system expects before you encode. Converting between variants afterward is just character substitution, but catching it early saves debugging time.
How to recognize Base64 in the wild
Base64 has a distinctive look: a long run of uppercase and lowercase letters, digits, and the occasional + or /, often terminating in one or two = signs, with a total length that is always a multiple of four. After you have seen a few, you will spot them in config files, URLs, and API responses without conscious effort.
The URL-safe variant is sneakier — minus and underscore replace plus and slash, and padding is frequently dropped — which is why JWT segments do not look classically Base64 at first glance. Context is your friend: three dot-separated segments shout JWT, while a data: prefix with ;base64, announces a data URI. When uncertain, try decoding — readable text or JSON out is confirmation.
Frequently asked questions
What characters are allowed in Base64?
A–Z, a–z, 0–9, +, and /, plus = for padding at the end. The URL-safe variant replaces + and / with - and _.
Why is Base64 output 33% larger?
Every 3 input bytes become 4 output characters — a fixed 4:3 ratio. The overhead is the price of representing binary data as safe text.
What is the difference between Base64 and base64url?
base64url replaces + with - and / with _, and usually omits padding, so the string is safe inside URLs. The underlying data is identical.
Can Base64 contain line breaks?
The MIME variant wraps lines every 76 characters for email. Standard and URL-safe forms are single-line; unexpected breaks usually mean the string was wrapped in transit.