What Base64 is, and what it is not

Base64 turns arbitrary binary data into plain text made of 64 safe characters. That is the whole idea. Everything else — the equals signs, the one-third size increase, the persistent belief that it hides something — follows from it.

The problem Base64 solves

A great deal of internet infrastructure was designed to carry text, and specifically seven-bit ASCII text. Email is the classic example: SMTP dates from 1982 and historically assumed seven-bit characters, with several byte values reserved as control codes.

Send raw binary — an image, a PDF, a zip — through a channel like that and it arrives corrupted. Bytes get stripped, reinterpreted as line endings, or mangled by a gateway trying to be helpful.

Base64 sidesteps the problem by re-expressing the binary using only letters, digits, plus and slash. Every one of those characters survives any text-handling system ever built. The data is unchanged; only its representation is.

How the encoding actually works

Base64 works on groups of three bytes at a time.

Three bytes is 24 bits. Split those 24 bits into four groups of six bits each. Six bits can hold a value from 0 to 63 — 64 possibilities, hence the name — and each value maps to one character from the alphabet A–Z, a–z, 0–9, + and /.

So three input bytes always become four output characters. Take the word Man: M is 77, a is 97, n is 110. In binary that is 01001101 01100001 01101110. Regrouped into sixes: 010011 010110 000101 101110, which is 19, 22, 5, 46, which maps to TWFu.

That 3-to-4 ratio is why Base64 makes data about 33% larger. It is not compression and it is not overhead you can tune away; it is arithmetic. A 3 MB image becomes roughly 4 MB of Base64. Our Base64 encoder shows both sizes so you can see the cost.

Why it ends in equals signs

The algorithm needs groups of three bytes, and real data rarely divides neatly by three.

If the final group has two bytes, it produces three characters and one = is appended. If it has one byte, it produces two characters and == is appended. If it divides evenly, there is no padding at all.

So the padding tells the decoder how many bytes to discard from the last group. It is not decoration, and it is not — as is sometimes assumed — a signature of encryption. A string ending in == simply had a length that left one byte over.

This is also why you can often guess Base64 on sight: a run of mixed-case letters and digits, length divisible by four, possibly ending in one or two equals signs.

It is not encryption, and never was

This deserves stating plainly because it causes real security failures.

Base64 provides no confidentiality whatsoever. There is no key. There is no secret. Anyone who sees the string can decode it instantly — it is a public, documented, reversible transformation, and every programming language has it built in.

Storing a password, an API key or a token as Base64 and thinking it is protected is equivalent to writing it backwards. It stops nobody. This mistake appears regularly in breached codebases and in configuration files committed to public repositories.

What you want instead depends on the job:

• To keep something secret, encrypt it. The file encryptor uses AES-GCM with a key derived from your passphrase via PBKDF2, which is a genuinely different category of thing.
• To verify something has not changed, hash it. The hash generator produces SHA-256 and friends; hashing is one-way by design, so it is not a way to store data you need back.
• To move binary safely through a text channel — that, and only that, is Base64's job.

Our guide to hashing, encryption and encoding lays out which of the three you need for which problem.

Where you actually meet it

• Email attachments. Every attachment you have ever sent travelled as Base64 inside a MIME message.
• Data URIs. src="data:image/png;base64,iVBOR..." embeds an image directly in HTML or CSS, saving a network request at the cost of a third more bytes.
• JSON Web Tokens. A JWT is three Base64url segments separated by dots. The middle one holds the claims — and is readable by anyone, which surprises people. The signature is what makes a JWT trustworthy, not the encoding.
• HTTP Basic authentication. Credentials are sent as Base64 of user:password. This is precisely why Basic auth over plain HTTP is unsafe: the credentials are effectively in clear text.
• Certificates and keys. PEM files are Base64 wrapped in BEGIN and END lines.

URL-safe Base64 and other variants

Standard Base64 uses + and /, both of which have meaning inside a URL — / is a path separator and + historically means a space in query strings. Putting standard Base64 in a URL breaks it.

Base64url solves this by substituting - for + and _ for /, and usually dropping the padding. This is what JWTs use. If you are encoding for a URL, the URL encoder handles percent encoding, which is the other, more common approach for text.

Related but distinct: Base32 uses only uppercase letters and digits 2–7, avoiding characters that look alike, which is why it appears in two-factor authentication secrets and Tor addresses. Hexadecimal is base 16 and doubles the size, which is why it is used for hashes and colours rather than for payloads — the number base converter handles those conversions, and the text to binary converter shows the same idea at the bit level.

Pikkit has the rest of the encoding tools, all running in your browser.