What Is Base64 Encoding and When Should You Actually Use It?

Base64 Sounds Scary, But It Isn't

If you've ever peeked at an HTML email template or cracked open a JSON Web Token, you've seen Base64. It's that wall of seemingly random characters — aGVsbG8gd29ybGQ= — that looks like it was produced by a cat walking across a keyboard.

But here's the thing: Base64 is one of the simplest, most widely used encoding schemes in computing. It shows up in email attachments, API payloads, CSS stylesheets, data URLs, and countless other places. Once you understand why it exists and how it works, you'll start recognizing it everywhere.

I've seen codebases where every icon was Base64-encoded inline — the HTML was 2 MB. I've also seen projects where a single 1x1 tracking pixel was served as an external file with its own HTTP request. Both are wrong. The key is knowing when Base64 helps and when it hurts.

What Is Base64?

Base64 is a binary-to-text encoding scheme. It takes any binary data — an image, a PDF, a zip file, literally any sequence of bytes — and represents it using only 64 specific ASCII characters:

A-Z  (26 characters)
a-z  (26 characters)
0-9  (10 characters)
+    (1 character)
/    (1 character)
=    (padding character)

That's 64 characters for the data (hence the name "Base64") plus = for padding. These 64 characters were specifically chosen because they're safe in virtually every text-based system — email, HTML, JSON, XML, URLs (with the URL-safe variant). They won't be misinterpreted as control characters, line breaks, or special syntax.

The formal specification lives in RFC 4648, published by the IETF. It defines not just standard Base64 but also variants like Base64url (which swaps +/ for -_ to be URL-safe) and Base32.

How Base64 Encoding Works

The algorithm is elegant in its simplicity. Here's the step-by-step process:

Step 1: Take 3 Bytes of Input

Base64 works on groups of 3 bytes (24 bits) at a time. Let's encode the word Hi!:

Character:  H         i         !
ASCII:      72        105       33
Binary:     01001000  01101001  00100001

Step 2: Split Into 6-Bit Groups

Concatenate all 24 bits, then split them into four groups of 6 bits each:

24 bits: 010010 000110 100100 100001
         ------  ------  ------  ------
Group:     18      6       36      33

Step 3: Map to Base64 Characters

Each 6-bit value (0-63) maps to one character in the Base64 alphabet:

18 → S
 6 → G
36 → k
33 → h

"Hi!" → "SGkh"

3 bytes in, 4 characters out. That ratio is constant and is exactly why Base64 increases data size by 33% (4/3 = 1.333). A 10 KB image becomes ~13.3 KB. A 1 MB photo becomes ~1.33 MB. This overhead is the price you pay for text-safe transport.

What About Padding?

When the input length isn't divisible by 3, Base64 adds = padding characters to fill out the final 4-character block:

• 1 leftover byte → 2 Base64 characters + ==
• 2 leftover bytes → 3 Base64 characters + =
• 0 leftover bytes → no padding needed

That's why you often see Base64 strings ending with one or two = signs. It's not decoration — it tells the decoder how many bytes to expect in the final group.

Why Base64 Exists

Base64 was born out of a fundamental problem: many transport protocols only handle text safely. When email was designed in the early 1980s (RFC 822), the SMTP protocol could only handle 7-bit ASCII. Try sending a JPEG through a channel that strips the 8th bit off every byte, and you'll get corrupted garbage.

Base64 solved this by encoding binary data into a safe subset of ASCII. Today, even though most systems handle 8-bit data fine, Base64 remains essential for:

• Email attachments — MIME still uses Base64 for non-text content (images, PDFs, documents)
• JSON payloads — JSON has no binary type, so binary data must be Base64-encoded into strings
• HTML/CSS embedding — data URLs let you inline images directly in markup or stylesheets
• URLs — the Base64url variant safely encodes data in query strings and path segments
• APIs and tokens — JWTs, basic auth headers, and many API responses use Base64
• XML and SOAP — binary data in XML documents is almost always Base64-encoded

Data URLs Explained

This is where Base64 intersects with web development most visibly. A data URL (formally "data URI") lets you embed a file directly in HTML or CSS instead of referencing an external URL. The format is:

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

For images, this typically looks like:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHx
gljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot">

That entire src attribute contains the full PNG image data. No separate HTTP request needed. The browser decodes the Base64 string and renders the image directly.

You can use data URLs in CSS too:

.icon-check {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bW...");
  background-size: 16px 16px;
}

According to MDN Web Docs, data URLs are supported in all modern browsers. The ;base64 part tells the browser the data is Base64-encoded rather than percent-encoded text.

When to Use Base64 for Images

Base64 is not inherently good or bad. Like any tool, it has a sweet spot. Here are the legitimate use cases:

Small Icons and UI Elements (Under 2 KB)

For tiny images — a 200-byte SVG checkmark, a 1 KB loading spinner — the overhead of a separate HTTP request (DNS lookup, TCP handshake, TLS negotiation) can exceed the size of the image itself. Inlining these as data URLs eliminates that round-trip entirely. The 33% size increase on 1 KB is just 333 extra bytes — trivial compared to HTTP overhead.

CSS Background Images

Small, repeated UI textures or icons used in CSS are excellent candidates. The Base64 data gets cached along with the stylesheet, and you avoid extra requests that would block rendering.

Email Templates

Email clients are notoriously unreliable with external images — Gmail, Outlook, and Apple Mail all handle remote images differently, often blocking them by default. Inlining small icons with Base64 data URLs ensures they display reliably without the user clicking "load images." This is common practice for logos and social media icons in transactional emails.

Single-File HTML Documents

Reports, invoices, or documentation that must be self-contained benefit from Base64 images. You can email a single .html file and everything renders correctly without external dependencies.

Avoiding CORS Issues in Development

During local development, cross-origin restrictions can prevent loading external images in canvas operations. Base64 data URLs bypass CORS entirely since no cross-origin request is made.

When NOT to Use Base64

This is where I've seen the most mistakes in production. Let me be blunt about what not to do:

Large Images (Anything Over 2-5 KB)

A 100 KB product photo becomes 133 KB when Base64-encoded, and it sits directly in your HTML. The browser can't start rendering the page until it parses all that text. Multiply this by 20 product images, and your HTML document is over 2.5 MB. I've literally seen this in production e-commerce sites — the HTML payload was larger than most video files.

Performance-Critical Pages

Base64 images in HTML block parsing. The browser must process the entire Base64 string before it can continue rendering. External images load in parallel via separate HTTP requests, which is almost always faster for anything non-trivial.

Cacheable, Reusable Assets

External images get their own cache entries. A logo served as /images/logo.webp is downloaded once and cached. A Base64 logo in the HTML is re-downloaded every time the HTML changes. For a site with frequent content updates, this means your users re-download the same images repeatedly.

When You Want Lazy Loading

You can't lazy-load a Base64 image. The loading="lazy" attribute and Intersection Observer patterns only work with external URLs. If you're building a long scrolling page, you need external images.

Base64 vs External Image Files: Performance Comparison

Here's a practical comparison to help you make the right choice:

A key nuance: with HTTP/2 and HTTP/3, the argument for Base64 is weaker than it used to be. These protocols multiplex requests over a single connection, so the overhead of additional image requests is much smaller. Google's web performance guidelines generally recommend external files with proper caching over inline data URLs for most images.

How to Convert Images to Base64

There are several ways to encode an image as Base64:

In JavaScript (Browser)

// Using FileReader
const reader = new FileReader();
reader.onload = () => console.log(reader.result);
reader.readAsDataURL(file);  // "data:image/png;base64,iVBOR..."

In the Terminal

# macOS
base64 -i image.png | pbcopy

# Linux
base64 image.png | xclip -selection clipboard

# Windows (PowerShell)
[Convert]::ToBase64String([IO.File]::ReadAllBytes("image.png")) | clip

In Python

import base64

with open("image.png", "rb") as f:
    encoded = base64.b64encode(f.read()).decode("utf-8")
    data_url = f"data:image/png;base64,{encoded}"

The Easy Way: Use Pixel Impeccable

If you'd rather skip the terminal commands and code, our Image to Base64 converter handles it in your browser. Drop an image in, get the Base64 string and ready-to-use HTML/CSS snippets out. Everything runs locally — your images never leave your device.

Frequently Asked Questions