What Is Base64 Encoding?

Base64 turns up everywhere — in email attachments, API tokens, data URIs, JWTs, configuration files — and it is almost universally misunderstood. Half the internet believes it is a form of encryption. It is not, and that misunderstanding has leaked a great many passwords. This guide explains what Base64 actually does, why it exists at all, and when you should and should not reach for it.

The problem Base64 solves

Computers store everything as bytes, and a byte can hold any of 256 values. But many systems that move data around were designed for text — specifically, for a limited set of safe printable characters.

Email is the classic case. The original email protocols were built to carry plain 7-bit ASCII text. Feed them raw binary — an image, a PDF — and things break: certain byte values are interpreted as control codes, some get silently mangled, and the message arrives corrupted.

Base64 is the workaround. It re-expresses arbitrary binary data using only 64 safe characters: A–Z, a–z, 0–9, plus + and /. The result is plain text that survives any text-only channel intact — and can be converted back to the exact original bytes.

How it works

The mechanism is a neat piece of arithmetic. Base64 takes 3 bytes (24 bits) at a time and re-slices them into 4 groups of 6 bits. Six bits can express 64 different values — exactly the size of the alphabet. Each group becomes one character.

So every 3 bytes of input become 4 characters of output. That ratio is the whole story, and it leads directly to Base64's main cost.

The 33% size penalty

Three bytes in, four characters out. The output is therefore about 33% larger than the input.

This is not a bug — it is the price of the guarantee. You are spending bandwidth and storage to buy safe passage through a text-only channel. But it means Base64 is a genuine cost, not a free transformation, and it is why you should not Base64-encode things casually. A 3 MB image becomes 4 MB of Base64.

Padding: what the = signs mean

Base64 works in groups of three bytes. If your data does not divide evenly by three, the final group is short — so Base64 pads the output with = characters to keep the length a multiple of four.

• Input length divisible by 3 → no padding.
• One byte left over → == at the end.
• Two bytes left over → a single =.

This is why Base64 strings so often end in = or ==. The padding carries no data; it is purely structural.

The big one: Base64 is not encryption

This deserves to be said as plainly as possible, because it is the source of real breaches.

Base64 is encoding. Encoding is not encryption.

• Encryption requires a key. Without the key, the data cannot be recovered. The purpose is secrecy.
• Encoding has no key. Anyone can reverse it, instantly, with no secret at all. The purpose is compatibility.

Base64 has no key. Decoding it is a single command, or a paste into any online decoder. It provides exactly zero security.

And yet people constantly Base64-encode passwords, API keys and config secrets, look at the scrambled-looking result, and feel reassured. That string is plaintext with extra steps. Anyone who can see it can read it.

If it needs to be secret, encrypt it. If it just needs to survive a text channel, encode it.

The same confusion powers a related mistake: HTTP Basic Authentication sends your username and password Base64-encoded. That is not protection — it is why Basic Auth is only safe over HTTPS, where the whole connection is genuinely encrypted.

Where you will actually meet Base64

• Email attachments. Every file you have ever emailed travelled as Base64.
• Data URIs. Embedding a small image directly in HTML or CSS as data:image/png;base64,..., avoiding a separate network request.
• JSON Web Tokens.The header and payload of a JWT are Base64-encoded — which is exactly why anyone can read a JWT's contents.
• APIs carrying binary data inside JSON, which is a text format and cannot hold raw bytes.
• Certificates and keys. The PEM format is Base64 wrapped in -----BEGIN----- markers.

URL-safe Base64

Standard Base64 uses + and /, and both are problematic in a URL: / is a path separator, and + can be interpreted as a space in query strings.

So there is a URL-safe variant that swaps them for - and _, and usually drops the = padding. This is the variant used inside JWTs. If a Base64 string fails to decode, a mismatched variant is a very common cause.

When to use it — and when not to

Use Base64 when:

• Binary data must travel through a text-only channel.
• You are embedding a genuinely tiny image or font to save a request.

Do not use Base64 when:

• You want secrecy. That is encryption's job.
• The data is large. The 33% penalty is real, and inlining a big image into your HTML makes the page heavier, uncacheable, and slower.

Frequently asked questions

Is Base64 secure? No. It offers no security whatsoever. Anyone can decode it instantly.

Does Base64 compress data? The opposite — it makes data about 33% larger.

Why does my Base64 string end in ==? Padding, because the input length was not a multiple of three. It is normal.

Can Base64 encode any file? Yes — it is byte-level, so it works on any data, of any type.

Encode or decode now

Use our Base64 Encoder/Decoder to convert text and Base64 in your browser — nothing is uploaded. To inline an image, try Image to Base64 (but first read when to use Base64 images). To see Base64 in action inside a token, use the JWT Decoder.