Base64 Explained: What It Is and When to Use It

Base64 shows up everywhere — in data URIs, JWTs, email attachments, and API payloads. But it’s often misunderstood. Let’s clear it up.

Why Base64 exists

Many systems were designed to carry text, not arbitrary bytes. Email bodies, JSON strings, and URLs can choke on raw binary or control characters. Base64 solves this by mapping every 3 bytes of binary onto 4 characters drawn from a safe 64-character alphabet: A–Z, a–z, 0–9, plus + and /.

Because 4 characters represent 3 bytes, Base64 output is about 33% larger than the input. That’s the trade-off for portability.

Standard vs. URL-safe

The characters + and / have special meaning in URLs. The URL-safe variant swaps them for - and _, and often drops the trailing = padding:

Standard:  aGVsbG8/d29ybGQ+
URL-safe:  aGVsbG8_d29ybGQ-

Our Base64 Encoder / Decoder supports both, and handles full Unicode correctly by encoding text as UTF-8 first.

Base64 is NOT encryption

This is the most important point. Base64 is reversible by anyone — there is no key and no secret. Never use it to “hide” passwords or tokens.

If you can decode it without a secret, it isn’t protecting anything.

When you actually need it

• Data URIs — embedding a small image directly in HTML or CSS.
• Email attachments — MIME encodes binary parts as Base64.
• JWT — the header and payload are Base64URL-encoded (the signature provides the security, not the encoding).
• Basic HTTP auth — credentials are Base64-encoded (which is exactly why Basic auth must only run over HTTPS).

Takeaways

• Base64 makes binary safe for text channels, at ~33% size cost.
• Use the URL-safe variant inside URLs and filenames.
• It encodes, it does not encrypt — treat encoded data as fully public.