Base64 Encoding, Explained

Base64 is one of those technologies you use constantly without noticing: it is inside JWTs, email attachments, data URIs, and HTTP Basic auth. Yet it is widely misunderstood — most importantly, many people think it provides some kind of security. It does not. This guide explains what Base64 actually does, why it exists, and where it belongs in your toolkit.

The problem Base64 solves

Some systems are text-only. Email bodies, JSON strings, URLs, and many HTTP headers were designed to carry printable ASCII characters, not arbitrary binary bytes. If you drop raw binary data into those channels, bytes get corrupted, reinterpreted, or stripped.

Base64 solves this by representing any binary data using just 64 safe, printable characters: A–Z, a–z, 0–9, +, and /. The result is pure text that survives any channel that accepts ASCII.

How it works

Base64 takes input three bytes (24 bits) at a time and splits those 24 bits into four groups of six bits. Each 6-bit group (a value from 0 to 63) maps to one character in the Base64 alphabet. That is why output is always a multiple of four characters, and why = padding appears when the input length is not a multiple of three.

Input text:   "Hi!"
Bytes:        72 105 33
Base64:       "SGkh"

The consequence: every 3 bytes become 4 characters, so encoded data is roughly 33% larger than the original. That size cost is the price of text-safety.

Base64 is not encryption

Base64 offers no secrecy whatsoever. Anyone can decode it in a fraction of a second.

Because it is trivially reversible with no key, Base64 must never be used to protect passwords, tokens, or personal data. If you need confidentiality, use real encryption (for example AES) and treat Base64 only as a way to make the encrypted bytes text-safe afterwards.

Base64 vs. Base64URL

Standard Base64 uses + and /, which have special meaning in URLs (and / is illegal in filenames). Base64URL is a small variant that swaps them for - and _ and usually omits the = padding:

Mixing the two is a common bug: a JWT segment (Base64URL) will not decode correctly with a strict standard-Base64 decoder, and vice versa.

Where you will meet Base64

• Data URIs — embedding an image directly in HTML or CSS with data:image/png;base64,... to avoid an extra request.
• JWTs — the header and payload are Base64URL-encoded JSON.
• HTTP Basic auth — Authorization: Basic carries a Base64 of username:password (which is exactly why Basic auth requires HTTPS).
• Email attachments — MIME encodes binary attachments as Base64.

When to use a data URI (and when not to)

• Good fit: tiny, reusable assets like a 1 KB icon or an SVG placeholder, where saving a request outweighs the 33% size bump.
• Poor fit: large images. The size increase adds up, the asset cannot be cached separately, and it bloats your HTML/CSS. A normal <img> reference is better.

Try it

The DevBox Base64 Encoder / Decoder encodes and decodes text instantly in your browser. Because JWT segments are Base64URL, the JWT guide is a natural next read.