What Is Base64, and Why Does It Make Things Bigger?

Base64 exists to solve one problem: some systems were built to carry text and will quietly corrupt anything else. Email bodies, URLs, HTTP headers, JSON string values and configuration files all expect printable characters. Feed raw binary through them and something in the chain will strip a byte, reinterpret a newline, or truncate at the first zero. Base64 rewrites that binary using only characters everything agrees on, so it arrives intact.

How it works, and where the third goes

The alphabet has 64 symbols: twenty-six uppercase letters, twenty-six lowercase, ten digits, and two extras. Sixty-four is two to the sixth, which means each symbol carries exactly six bits. A byte carries eight. Those numbers do not divide, so the encoder works in groups: it takes three bytes, which is twenty-four bits, and splits them into four six-bit chunks.

3 bytes in   =  24 bits  =  4 characters out

"Man"  ->  01001101 01100001 01101110
           010011 010110 000101 101110
              T      W      F      u

Three bytes become four characters, so the output is four thirds of the input. That is the familiar thirty-three per cent overhead, and it is not an implementation detail anyone can optimise away — it falls straight out of the arithmetic. Anything claiming smaller output is not Base64.

What the equals signs are for

Input rarely divides neatly into groups of three. When one or two bytes are left over, the encoder pads the final group with equals signs so the output length is always a multiple of four. One equals sign means the last group held two bytes; two mean it held one. Some decoders accept unpadded input and some reject it, which is why stripping the padding to save two characters tends to cause a bug further down the pipe.

The URL-safe variant

Standard Base64 uses plus and slash as its last two symbols. Both mean something else in a URL — a slash separates path segments, and a plus is read as a space in form-encoded data. The base64url variant swaps them for hyphen and underscore, and usually drops the padding too, because an equals sign is also reserved. This is the variant JSON Web Tokens use, which is why a token can be pasted into an address bar unharmed.

It is not encryption, and this matters

Base64 is an encoding, not a cipher. There is no key, nothing is secret, and reversing it takes one function call. Treating it as protection is a recurring source of real security incidents: credentials sit Base64-encoded in configuration files, and the people who put them there believed something was being hidden. If content needs to stay private it needs encryption. Base64 only makes binary survive a text-shaped pipe.

Encoding answers "will this arrive intact?". Encryption answers "can anyone else read it?". They are different questions.

The Unicode trap

Base64 encodes bytes, but text is not bytes until you choose an encoding. In the browser the built-in encoder historically threw on any character above the Latin-1 range, so an emoji or an accented name would fail outright. The fix is to convert the text to UTF-8 bytes first and encode those. Any tool that handles Unicode correctly is doing exactly that step for you, and any that throws on an emoji has skipped it.

When to reach for it, and when not

• Embedding a small image or font directly in CSS or HTML as a data URI, saving a request.
• Putting binary into a JSON field, which has no binary type of its own.
• Sending an attachment through email, which is where the format came from.
• Carrying a token or a signature through a URL, using the base64url variant.

Against that, remember what the third costs. Inlining a large image as a data URI makes the containing file bigger, removes it from the browser cache as a separate entry, and stops it being fetched in parallel. Below a couple of kilobytes that trade is usually worth making; well above it, rarely.