Base64 Explained: How Binary Becomes Text — and Why It's Not Encryption

Open a web page's source and you'll eventually trip over something like data:image/png;base64,iVBORw0KGgo…, or the eyJ that begins every JWT, or a -----BEGIN CERTIFICATE----- block full of dense gibberish. All three are the same trick: Base64, quietly doing one of the most common and least understood jobs on the internet.

Base64's entire purpose is to let binary data travel safely through channels that were only ever built for text. It's plumbing — unglamorous, everywhere, and routinely mistaken for something it isn't. Let's take it apart.

The problem Base64 solves

A great deal of the internet is text-only by design. Email was built to carry 7-bit ASCII. URLs, JSON, XML, HTML, and many config formats all expect printable characters. Binary data — an image, a cryptographic key, a compressed file — is just a stream of arbitrary bytes, and many of those byte values are control codes, invisible characters, or sequences that a text channel will happily mangle, truncate, or reject.

You can't paste a raw PNG into a JSON field and expect it to survive. Base64 is the workaround: it maps any sequence of bytes onto a small, safe alphabet of 64 printable characters that will pass through anything that handles text. Encode on one side, decode on the other, and the original bytes come out intact.

How it works: three bytes become four characters

The mechanism is a neat bit of bit-shuffling. Computers store data in 8-bit bytes; Base64 reslices that data into 6-bit groups, because 6 bits gives exactly 64 possible values — one for each character in the alphabet.

Take three bytes (24 bits) and regroup them into four 6-bit chunks. Each chunk is a number from 0 to 63, and each number maps to one character. So every three bytes of input become four characters of output. Here's the canonical example, encoding the word Man:

"Man"  →  01001101 01100001 01101110   (3 bytes = 24 bits)
       →  010011 010110 000101 101110   (four 6-bit groups)
       →  19     22     5      46        (their values, 0–63)
       →  T      W      F      u         ("TWFu")

So Man encodes to TWFu. You can run this both ways — text to Base64 and back — with our Base64 encoder and decoder.

The alphabet

The 64 characters are fixed and ordered by the Base64 standard (RFC 4648): A–Z are values 0 to 25, a–z are 26 to 51, 0–9 are 52 to 61, and the last two slots go to + (62) and / (63). A sixty-fifth character, =, isn't part of the alphabet itself — it's used for padding, which is where the trailing equals signs you've probably noticed come from.

Padding and the = signs

The "three bytes to four characters" rule only works cleanly when the input length is a multiple of three. When it isn't, Base64 pads the final group out and marks the shortfall with =:

"Man"  →  TWFu   (3 bytes — no padding needed)
"Ma"   →  TWE=   (2 bytes — one =)
"M"    →  TQ==   (1 byte — two =)

The padding keeps the output length a tidy multiple of four, so a decoder always knows where it stands. Some modern uses — Base64url among them — drop the padding entirely, because the decoder can work the length out on its own.

Base64url: the URL-safe cousin

There's one snag with the standard alphabet: + and / have special meanings in URLs and file paths. A Base64 string with a / in it can break a path; a + can be misread as a space. So a variant called Base64url swaps those two characters for - and _, which are safe anywhere. It's the same encoding in every other respect.

This is the version inside every JSON Web Token — each of a JWT's three parts is Base64url, which is exactly why you can decode and read them so easily. It also turns up in URL parameters, filenames, and anywhere a Base64 string needs to survive being part of an address.

Where you'll actually see it

Once you know the shape of it, Base64 is hard to un-see:

• Data URIs — small images and fonts embedded directly in HTML or CSS as data:…;base64,…, saving a separate network request.
• Email attachments — MIME encodes every non-text attachment in Base64 so it survives mail servers that expect plain text.
• PEM keys and certificates — the dense text between the BEGIN and END lines of a TLS certificate or private key is Base64-encoded binary.
• HTTP Basic authentication — the Authorization: Basic … header is simply username:password run through Base64. Which is a useful warning, as we're about to see.
• Binary inside JSON or XML — any time a structured text format needs to carry raw bytes.

The roughly 33% tax

Base64 isn't free. Turning every three bytes into four characters makes the output about a third larger than the input. That overhead is why you don't Base64-encode everything by default — if a channel can carry binary directly, that's almost always the better choice. Base64 earns its place only when the surrounding format insists on text. Embedding a large image as a data URI, for instance, makes the HTML noticeably heavier than just linking to the image file.

Base64 is not encryption

Here's the misconception worth ending on, because it causes real security mistakes. Base64 looks scrambled, so people assume it's a way to hide information. It is not. There is no key, no secret, nothing to crack — the transformation is completely public and completely reversible. Anyone who sees a Base64 string can decode it back to the original in the time it takes to paste it into a decoder.

It helps to keep three ideas separate:

• Encoding (Base64) — reversible by anyone, no key involved. Its job is safe transport, not secrecy.
• Encryption — reversible only with the right key. Its job is confidentiality.
• Hashing — a one-way fingerprint that can't be reversed at all. Its job is integrity and verification, and it's worth understanding the difference with a hash generator.

This is why "encoding" a password in Base64 protects nothing, why the data in a JWT is readable by anyone holding the token, and why HTTP Basic authentication — being little more than Base64-wrapped credentials — is only safe over an encrypted HTTPS connection. The Base64 part adds zero confidentiality. If something needs to stay private, it needs encryption; if you need to verify it hasn't changed, you need a hash. Base64 does neither.

The takeaway

Base64 is one of the internet's most reliable pieces of plumbing: a simple, lossless way to carry binary data through anything that speaks text. It makes images embeddable, attachments mailable, and keys pasteable — and it hides absolutely nothing in the process. When you spot it, remember that you can always read what's inside. Try it both ways with our Base64 encoder and decoder.