The string hiding at the end of every URL
You have almost certainly seen Base64 without knowing it. An embedded image in an email or a web page often appears as a data URL, which looks like this: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgA... The part after base64, is Base64. It is the image itself, written as text so it can travel inside a text-based format.
The same trick appears in JSON Web Tokens, where the payload between the two dots is Base64url — a URL-safe variant of Base64 that swaps the + and / characters for - and _. Authentication systems, APIs, and configuration files all use Base64 for the same reason: to carry binary data through channels that only understand text.
Why bytes need a disguise in the first place
Email was designed in an era when messages were plain text, and early mail protocols assumed every byte was a printable character. A binary byte — an image fragment, a control character, a byte that is not valid UTF-8 — could be mangled, dropped, or reinterpreted by a mail server along the way.
Base64 solves the problem by translating binary data into a restricted alphabet: the 64 characters A–Z, a–z, 0–9, +, and /. Those 64 characters are printable, unambiguous, and identical on every system that matters. The data survives the journey, and the receiver reverses the encoding to recover the original bytes exactly.
The alphabet, and why it is exactly 64 characters
The choice of 64 is not arbitrary: 64 is a power of two, and one Base64 character carries exactly six bits of information. The alphabet is laid out in a memorable order: A through Z map to the values 0 through 25, a through z to 26 through 51, 0 through 9 to 52 through 61, + is 62, and / is 63.
Six bits do not divide evenly into the eight-bit bytes computers use, and that mismatch is the engine of everything else in this article — the grouping into threes, the 33 percent size increase, and the padding that ends so many Base64 strings in equals signs.
Encoding: three bytes become four characters
The encoder works in groups of three bytes — 24 bits — and splits each group into four chunks of six bits. Each chunk becomes one alphabet character. Three bytes in, four characters out, nothing lost.
Here is the real math for the word Hi!. Its bytes are 01001000, 01101001, and 00100001. Joined together, they form 24 bits: 010010 000110 100100 100001. Split into four chunks, each chunk has a value: 18, 6, 36, and 33. The alphabet maps those values to S, G, k, and h. Three bytes, four characters: Hi! encodes to SGkh.
Padding: why SGk= ends with an equals sign
Groups of three work perfectly until the input length is not a multiple of three. Take the word Hi — two bytes, 16 bits. Sixteen bits split into two complete six-bit chunks, with four bits left over. The encoder pads the final chunk with zeroes to six bits, encodes it, and adds one = for the single padding byte.
The rule is simple: two remaining bytes produce one =, one remaining byte produces two. That is why short Base64 strings so often end in = or ==. The equals signs are not decoration or checksum — they tell the decoder exactly how many bytes the final group contains, so the original length can be recovered precisely.
Decoding by hand: reversing the whole thing
Decoding is encoding in reverse, and you can do it on paper. Take SGk= from the previous section. Look up each character in the alphabet: S is 18, G is 6, k is 36, and the = says the final group has one padding byte. Write the values as six-bit chunks: 010010 000110 100100, regroup them into bytes — 01001000 01101001 — and the bytes are 72 and 105, which is the word Hi.
That is the entire algorithm, and it is why the "security" claim around Base64 is so easy to test: anyone with the alphabet table can do what you just did with a pencil.
Where Base64 actually lives
Email attachments travel as MIME-encoded Base64. Images on the web are embedded as data URLs. JSON Web Tokens carry their payloads in Base64url. Configuration files store secrets — poorly, for this reason — and API payloads ship binary values in Base64 because JSON has no byte type.
The encoding also appears where you least expect it: in the favicons of old websites, in email signatures, and in the copy-paste blocks that let you share small images without a file. Everywhere the pattern is the same: bytes need to cross a text-only boundary, and Base64 is the toll bridge.
The myth that never dies: Base64 is not encryption
Because Base64 output looks scrambled, it is routinely mistaken for encryption. The mistake is understandable and completely wrong. Base64 uses no key, and as you just saw, the decode can be done with a pencil and a table. Anyone who sees a Base64 string can read its contents in seconds.
The practical rule: never store passwords, tokens, or secrets in Base64 and assume they are protected. A string that ends in == and uses only letters, digits, plus, and slash is not a mystery — it is a wrapped package, and the wrapping is transparent. Use Base64 for what it is: a reliable transport format, not a safe.