Where Is Base64 Hiding? From Email Attachments to JWT Tokens — An Encoding Technology You Use Every Day Without Knowing It

Open your browser's developer tools and look at the network requests on almost any website. You'll almost certainly find a long string of Base64 somewhere — a Bearer token in an Authorization header, a data URL in CSS, an image field in an API response. Base64 is everywhere. Yet most people's understanding of it stops at "it turns things into gibberish," which misses most of what's actually happening.

1. What Is Base64? Start with "Why Does It Exist?"

Computers store everything as binary (0s and 1s), but many early communication protocols (SMTP, HTTP/1.1) were designed to carry only plain text (ASCII characters). When you need to send an image, a PDF, or any binary data through these text-only channels, the protocol can't handle it correctly.

Base64 solves this straightforwardly: take every 3 bytes (24 bits) of binary data, regroup them into four 6-bit numbers, and represent each using a 64-character alphabet (A–Z, a–z, 0–9, +, /). The result: any binary data can be expressed using only printable text characters.

2. Base64 Inside Every Email Attachment (MIME)

SMTP — the protocol that sends email — was originally designed for 7-bit ASCII text only. Sending attachments (images, PDFs, Word documents) requires the MIME (Multipurpose Internet Mail Extensions) standard, and MIME attachments are typically Base64-encoded.

If you "view raw source" on any email with an attachment, you'll see something like this:

Content-Type: image/png; name="logo.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAABHNCSVQICAgI
fAhkiAAAAAlwSFlzAAAApgAAAKYB3X3/OAAAABl0RVh0U29mdHdhcmUAd3d3
...

That wall of seemingly random text is your image file — Base64-encoded and split into 76-character lines so SMTP can transport it without corruption.

3. JWT Tokens: The Most Common Base64 in Login Systems

If you've used any website or API that requires login, you've almost certainly encountered a JWT (JSON Web Token). A JWT looks like three chunks of Base64 separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiJ1c2VyMTIzIiwiZXhwIjoxNzQ4MDAwMDAwfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decode the first part and you get:

{"alg":"HS256","typ":"JWT"}

Decode the second part:

{"sub":"user123","exp":1748000000}

The header and payload of a JWT are just Base64url-encoded JSON (Base64url is a variant that uses - and _ instead of + and /, avoiding percent-encoding issues in URLs). The third part is the cryptographic signature that verifies the first two parts haven't been tampered with.

Critical point: the first two parts of a JWT are not encrypted. Anyone can decode them instantly. This is why you should never put passwords or sensitive data in a JWT — only information the server needs to identify you (user ID, roles, expiry time).

4. Data URLs: Images Embedded Directly in HTML and CSS

There's a special URL format called a Data URL that lets you embed an entire file directly inside HTML or CSS, eliminating the need for a separate HTTP request:

<img src="data:image/png;base64,iVBORw0KGgo...">

/* Or in CSS */
.icon {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxu...");
}

This technique is most useful in:

• Email templates: Prevents email clients from blocking externally hosted images
• Small icons: Reduces HTTP request count (more relevant in HTTP/1.1 than HTTP/2)
• Offline-capable apps: Packages all necessary assets into the HTML itself
• Single-file HTML: Creates a fully self-contained document

5. HTTP Basic Auth: Credentials in Base64

HTTP Basic Authentication encodes credentials as username:password in Base64:

Authorization: Basic dXNlcjpwYXNzd29yZA==

Decoding dXNlcjpwYXNzd29yZA== gives user:password immediately.

Basic Auth's Base64 is not encryption — anyone who intercepts the header can decode it instantly. This is why Basic Auth must always be used with HTTPS, or you're effectively sending credentials in plaintext.

6. Three Common Misconceptions About Base64

Misconception 1: Base64 is encryption

Not even close. Base64 is encoding — it changes the representation of data, but anyone can decode it instantly with no key required. Real encryption (like AES) makes data unreadable without the correct decryption key.

Misconception 2: Base64 compresses data

The opposite: Base64 makes data about 33% larger. Every 3 bytes becomes 4 Base64 characters. You're trading size for text-safe representation.

Misconception 3: The trailing = signs are cryptographic

They're alignment padding. Base64 processes 3 bytes at a time. If the input length isn't a multiple of 3, = characters pad the output to the next multiple of 4. One or two = signs mean one or two bytes of padding were added.

When to Use Base64 (and When Not To)

Summary

• Base64 converts binary data into 64 printable text characters, enabling it to travel through text-only protocols
• Email attachments (MIME), JWT tokens, Data URLs, and HTTP Basic Auth are its most common applications
• JWT headers and payloads are Base64url-encoded JSON — not encrypted, readable by anyone
• Base64 is not encryption; it increases data size by about 33%
• URLs require the Base64url variant (- and _ instead of + and /)