What Is Base64 Encoding? A Plain-English Guide (and Why It's Not Encryption)

You have seen it: a long string of letters and numbers, maybe ending in one or two equals signs, sitting in a JWT, an email source, or an image tag. That is Base64, one of the most common encodings in computing — and one that a surprising number of developers use every day without knowing what it actually does, or worse, believing it does something it does not. This guide explains Base64 in plain English: what it is, why it exists, where you will meet it, and the one dangerous misconception that causes real security incidents.

What Base64 actually is

Base64 is a way to represent binary data — any bytes at all — using only 64 printable text characters: the 26 uppercase letters, the 26 lowercase letters, the 10 digits, and two symbols, plus (+) and slash (/). The equals sign (=) is used as padding at the end. That is the whole alphabet, and it is where the name comes from. Every character in Base64 output is a safe, printable character with no control codes or ambiguous whitespace, which is exactly the point.

The reason it exists is historical and still relevant. The internet's core protocols — email over SMTP, HTTP headers, and others — were designed for plain text. Feed them raw binary data, like an image or an encrypted blob, and certain byte values get misinterpreted as control characters and corrupt the data. Base64 solves this by converting binary into a subset of text that survives any text-based channel intact. It is a translator between the binary world and the text world.

How it works, briefly

The algorithm takes your input three bytes at a time. Three bytes is 24 bits, which it splits into four groups of 6 bits each, and each 6-bit group maps to one of the 64 characters. So every 3 bytes of input become exactly 4 characters of output. When your input is not a clean multiple of 3 bytes, Base64 pads the output with equals signs — one = if the last group had 2 bytes, two == if it had just 1 byte — so the result is always a multiple of 4 characters. That is what those trailing equals signs mean: they tell the decoder how many real bytes were in the final group.

This 3-to-4 ratio has a direct consequence: Base64 output is about 33% larger than the original data. A 1 MB image becomes roughly 1.37 MB encoded. That size overhead is the price you pay for text safety, and it is why Base64 is great for small things and a poor choice for large ones.

Where you will meet Base64

Base64 is everywhere once you know to look. Data URLs embed a file directly in HTML or CSS — the data:image/png;base64,... you sometimes see in an image tag or background style — letting a small icon load with the page instead of as a separate request. Email attachments are Base64-encoded so binary files survive text-based mail transport; every attachment you have ever sent traveled this way, which is why a raw email file is larger than the file it carries.

JSON Web Tokens (JWTs) encode their header and payload in a URL-safe variant of Base64. HTTP Basic Authentication sends your username and password as Base64 in a header. APIs that accept file uploads inside a JSON body Base64-encode the file, because JSON is text and cannot hold raw bytes. And PEM files — SSL certificates, SSH keys — are Base64-encoded binary wrapped between BEGIN and END header lines. The same simple encoding underlies all of it.

The dangerous myth: Base64 is not encryption

This is the single most important thing to understand, because getting it wrong causes real security breaches. Base64 provides zero security. It is not encryption. Anyone with the encoded string can decode it instantly, with no key, in one line in any browser console. The string c2VjcmV0 decodes to "secret" in about one second.

The danger comes from how Base64 looks. A Base64 string appears scrambled and random, visually similar to encrypted data, which fools people into thinking it is protected. This leads to genuine incidents: a developer commits a config file with Base64-encoded database credentials to version control, believing the encoding hides them — it does not. An API logs the Authorization header, and a reviewer "can't read" the Base64 password, so it sits in the logs as effectively plain text until someone decodes it in five seconds. Storing an API key as Base64 in a database looks opaque but protects nothing.

URL-safe Base64 (Base64url)

Standard Base64 uses + and /, but both have special meaning in URLs — + can mean a space in a query string, and / delimits path segments. So a URL-safe variant called Base64url replaces + with - (minus) and / with _ (underscore), and usually drops the = padding, which would otherwise need percent-encoding in a URL. This is the variant JWTs, OAuth tokens, and URL-safe cookies use. If you ever feed a JWT segment into a strict standard Base64 decoder and get an error or garbage, this is usually why: you need to convert the URL-safe characters back and restore the padding first.

The Unicode gotcha

One subtle bug bites developers who Base64-encode non-English text. The classic browser function btoa() assumes each character is a single byte, which breaks on accented letters, emoji, or any non-Latin script. The fix is to encode the text as UTF-8 first, then Base64-encode the resulting bytes — otherwise "café" or "こんにちは" comes out corrupted. A good encoder handles this UTF-8 step for you, so accented text and emoji round-trip cleanly.

When to use it, when to avoid it

Reach for Base64 when you need to move small binary data through a text-only channel: a tiny inline icon, a token, a small file inside a JSON payload, a credential you are debugging. Avoid it for large binary files in performance-sensitive paths — the 33% size penalty and the loss of separate caching make a real file or a multipart upload the better choice. And never use it as a security layer. Keep it in its lane — representation and transport — and Base64 is a reliable, universal tool.