Why does Base64 exist?

Computers store and transmit data as binary — sequences of 8-bit bytes that can represent values from 0 to 255. Many of these byte values correspond to non-printable control characters (newlines, null bytes, escape sequences) that cause problems in text-based systems.

Email, the original use case for Base64, was designed to carry 7-bit ASCII text. Attaching a binary image or a PDF — which contains arbitrary byte values — to an email would corrupt it. Base64 solves this by converting any binary data into a string that uses only 64 printable, universally safe ASCII characters. The receiving system decodes it back to the original binary.

The Base64 alphabet

Base64 uses exactly 64 characters: A–Z (26), a–z (26), 0–9 (10), + (1), and / (1). Each character represents 6 bits of data.

# Encoding works in groups of 3 bytes (24 bits) → 4 Base64 characters (24 bits)

Input:  "Man"
Bytes:  77    97    110
Binary: 01001101 01100001 01101110
        ┌──────────────────────────┐
Groups: 010011  010110  000101  101110
Values: 19      22      5       46
Base64: T       W       F       u

Output: "TWFu"

Padding with =

Base64 encodes 3 bytes at a time. If the input length is not a multiple of 3, padding characters (=) are appended to make the output length a multiple of 4:

"Ma"  → 2 bytes → TWE=   (one padding character)
"M"   → 1 byte  → TQ==   (two padding characters)
"Man" → 3 bytes → TWFu   (no padding needed)

The = padding tells the decoder how many real bytes to expect at the end. Some systems omit padding (notably JWT headers/payloads) since the decoder can infer it from the string length.

Base64 vs Base64url

The standard Base64 alphabet includes + and /, which have special meanings in URLs (+ encodes a space in form data; / separates path segments). Base64url replaces these with - and _ respectively, making the output safe to embed directly in URLs and filenames without percent-encoding.

JWT (JSON Web Tokens) use Base64url for their header and payload sections. That's why decoded JWTs look like eyJhbGciOiJIUzI1NiJ9 — the leading ey is always the Base64url encoding of { (the start of a JSON object).

# Decode a JWT header in bash:
echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" | base64 -d
# Output: {"alg":"HS256","typ":"JWT"}

Data URIs: embedding images in HTML and CSS

A data URI lets you embed file content directly in an HTML or CSS document instead of linking to an external file. The format is:

data:[mediatype][;base64],<data>

# Small PNG icon embedded directly in HTML:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==" alt="1x1 pixel" />

# Embedding a small font in CSS:
@font-face {
  font-family: 'MyFont';
  src: url('data:font/woff2;base64,d09GMgAB...') format('woff2');
}

Data URIs are useful for small images and icons that you want to ship inline to avoid extra HTTP requests. For large images, they are counterproductive: the Base64 representation is about 33% larger than the original binary, and browsers cannot cache data URIs the same way they cache external files.

Base64 is NOT encryption

This is the most important thing to understand about Base64: it provides zero security. Anyone can decode a Base64 string instantly. There is no key, no secret, no protection. Encoding something in Base64 and calling it "encoded" does not make it safe to transmit or store sensitive information.

This mistake shows up in the wild more than you would expect — credentials passed in request bodies as Base64, API keys "hidden" in Base64-encoded config files, sensitive data "obfuscated" in Base64 in client-side JavaScript. All of these are fully readable by anyone who looks at the data.

If you need to protect data, use encryption (AES, RSA) or a proper secrets management solution. Base64 is a transport encoding, not a security mechanism.