What is Base64 encoding (and when to use it)

A plain-English look at the encoding that quietly powers data URIs, email and JWTs.

Computers handle two broad kinds of data: text and raw bytes. Most of the internet’s plumbing — email headers, JSON documents, URLs, HTTP headers — was designed to carry text, and specifically a narrow, well-behaved slice of ASCII. Push raw binary (an image, a font, an encryption key) through one of those channels and bytes get mangled: a stray newline gets normalised, a high byte gets stripped, and the file arrives corrupt. Base64 solves exactly this problem. It rewrites any binary blob using a tiny alphabet of characters that survive transport intact.

How Base64 actually works

The name is literal: Base64 encodes data using 64 characters — A–Z, a–z, 0–9, plus + and /. Sixty-four values is exactly six bits (2⁶), and that number is the whole trick. The encoder takes your bytes three at a time — that’s 24 bits — and re-slices those same 24 bits into four groups of six. Each 6-bit group becomes one character from the alphabet. So every 3 input bytes turn into 4 output characters.

Because 4 characters carry what 3 bytes did, Base64 output is roughly 33% larger than the original (4 ÷ 3 ≈ 1.33). When the input length isn’t a clean multiple of three, the encoder pads the final block with one or two = characters so the output length stays a multiple of four. That = is padding, not data — it tells the decoder how many bytes the last group really represented.

A quick example: the three letters Man become TWFu. The single byte M becomes TQ== (two padding characters), and the two bytes Ma become TWE= (one). You can watch this happen in both directions with the Base64 encoder & decoder — paste text in, get the encoding out, and decode it straight back.

What Base64 is — and isn’t

This is the single most important thing to internalise: Base64 is an encoding, not a security measure. It scrambles nothing. The mapping is public and reversible by anyone, instantly, with no key. Three common misconceptions are worth killing off:

Not encryption

Anyone can decode Base64 in one step. Never use it to “hide” passwords, tokens or secrets — it offers zero confidentiality.

Not compression

It makes data about 33% bigger, not smaller. If size matters, compress first, then encode the compressed bytes.

Not a hash

It’s fully reversible and isn’t a fixed-length fingerprint. Hashing (SHA-256, etc.) is a one-way function; Base64 is a round trip.

The right mental model: Base64 is a safe envelope for shipping binary through a text-only door. That’s the whole job.

Where you’ll meet it in the wild

Once you know the pattern, you start spotting Base64 everywhere. These are the most common places it shows up:

Use case	Why Base64 is needed
Data URIs	A small image or font can be embedded directly in HTML or CSS as `data:image/png;base64,…`, saving an extra network request.
Email attachments (MIME)	SMTP was built for 7-bit text. MIME uses Base64 to carry binary attachments through mail servers without corruption.
Binary inside JSON / XML	These formats have no native binary type, so raw bytes (a thumbnail, a certificate) are stored as a Base64 string field.
JWT header & payload	A JSON Web Token is three Base64url-encoded parts joined by dots — the header and payload are simply encoded JSON, not encrypted.

That last one trips people up constantly: the readable-looking middle of a JWT is just Base64, so anyone can decode and read its claims. The token’s integrity comes from the cryptographic signature in the third part, not from the encoding.

The URL-safe variant

Standard Base64 uses + and /, and both cause trouble in URLs. / is a path separator, and + is often interpreted as a space in query strings. The URL-safe (Base64url) variant fixes this by swapping two characters: + becomes - and / becomes _. Padding = is also frequently dropped, since it can be re-derived from the length. This is the variant JWTs use, which is why you’ll see those tokens contain - and _ but never + or /.

Need to encode or decode something right now? The Base64 encoder & decoder handles both standard and URL-safe output and runs entirely in your browser — nothing you paste is ever uploaded, so it’s safe even for certificates or keys.

Base64url solves the binary-to-URL problem, but it isn’t the same job as percent encoding. When you need to make ordinary text safe inside a URL — escaping spaces, ampersands, slashes and other reserved characters in a query parameter — that’s URL encoding, not Base64. Reach for the URL encoder & decoder for that, and keep Base64 for the cases where you’re genuinely moving binary data.

When not to use it

The 33% size penalty is cheap for a tiny icon but expensive at scale. Don’t Base64-encode large files — a multi-megabyte video inlined as a data URI bloats your HTML, can’t be cached separately, and forces the whole document to download before the asset appears. For anything sizeable, serve the file normally over HTTP and link to it. Likewise, never lean on Base64 for privacy: if data needs to be hidden, encrypt it; if it needs to be verified, sign or hash it. Used for its actual purpose — safely ferrying binary through text-only channels — Base64 is simple, reliable, and quietly indispensable.

Related tools: Base64 encoder & decoder · URL encoder