What Is Base64 Encoding and When Should You Actually Use It

You've Probably Used Base64 Without Knowing It

Ever inspected the source of a webpage and seen a huge wall of random-looking characters that starts with something like data:image/png;base64,iVBORw0KGgo...? That's Base64. Or maybe you've worked with an API that sends image data as a long string instead of a file. Also Base64.

It's one of those things that's absolutely everywhere in software development, but most people only vaguely understand what it actually does. So let's fix that.

What Base64 Actually Is (Without the Jargon)

Computers speak in bytes—raw binary data. A JPEG photo, a PDF document, a ZIP archive—they're all just sequences of bytes. And bytes can have any value from 0 to 255.

The problem? Not everything can handle arbitrary bytes. Email was designed for text. JSON is text. HTML is text. URLs are text. Try stuffing a raw binary file into any of these systems and things break spectacularly. Random characters get misinterpreted, null bytes terminate strings early, and encoding mismatches corrupt your data.

Base64 solves this by converting binary data into a set of 64 "safe" characters that work everywhere:A-Z, a-z, 0-9, +, and / (plus = for padding). That's it. No weird control characters, no null bytes, no encoding issues. Just plain text that plays nice with every text-based system in existence.

How the Conversion Works

The math is actually pretty elegant. Base64 takes your binary data and processes it in chunks of 3 bytes (24 bits). It splits those 24 bits into four groups of 6 bits each. Each 6-bit group maps to one of the 64 characters in the Base64 alphabet. So 3 bytes of input become 4 characters of output.

What about when your data isn't a multiple of 3 bytes? That's where the = padding comes in. If there's one byte left over, you get two padding characters (==). Two bytes left over? One padding character (=). The padding tells the decoder exactly how many real bytes are in the last chunk.

The 33% Tax: Why Base64 Makes Everything Bigger

This is the most important thing to understand about Base64: it always increases the size of your data by roughly one-third. A 30 KB image becomes about 40 KB. A 3 MB PDF becomes 4 MB. Always.

Why? Because you're representing every 3 bytes with 4 characters. That's a 4/3 ratio, which works out to about 133% of the original size. You're trading compactness for compatibility.

This matters because people sometimes use Base64 in places where they don't need to, bloating their applications without realizing it. We'll get into the "when to use it" and "when to avoid it" later.

Base64 Is NOT Encryption (Please Stop Using It Like It Is)

This comes up more often than you'd think. People see a Base64 string likecGFzc3dvcmQxMjM= and think "well, nobody can read that, so it's secure." Wrong. Anyone with access to a browser console, a command line, or literally any Base64 decoder can reveal that string is just password123 in about two seconds.

HTTP Basic Authentication uses Base64 to encode credentials, which is why it should always be used over HTTPS. The Base64 is just a transport encoding, not a security layer. The encryption comes from TLS/SSL, not from the Base64.

Where Base64 Actually Makes Sense

1. Data URIs in HTML and CSS

This is probably the most common use case you'll encounter. Instead of referencing an external image file, you embed it directly in your code:

This eliminates an HTTP request, which is great for tiny images like icons, 1x1 tracking pixels, or small SVGs. For small assets (under 2-5 KB), the saved network request often outweighs the 33% size increase. For anything larger, you're usually better off with a normal file reference.

2. Embedding Images in Emails

Email is fundamentally a text-based protocol (MIME). When you attach an image or embed it inline, the email client Base64-encodes the binary data so it can travel through the email system as text. This happens automatically—you don't usually see it—but it's why email attachments are always larger than the original file.

3. JSON APIs and Data Transfer

JSON doesn't support binary data. If an API needs to send or receive a file (a user's avatar, a generated PDF, a signature image), Base64 is the standard approach:

{
  "user": "jane",
  "avatar": "data:image/jpeg;base64,/9j/4AAQ..."
}

It's not the most efficient way to transfer files (multipart form data is better for large files), but for small payloads it keeps your API simple and consistent.

4. Storing Binary in Text-Only Databases

Sometimes you need to store a small binary blob (a thumbnail, a signature, a QR code) in a database column that only accepts text. Base64 lets you do that without needing a separate binary/BLOB column or file storage system. Again—only practical for small data.

Where Base64 Is a Bad Idea

Base64 Variants You Might Encounter

Not all Base64 is the same. There are a few variants you might run into:

The URL-safe variant replaces + with - and / with _ because both+ and / have special meaning in URLs. If you've ever worked with JWTs (JSON Web Tokens), you've used URL-safe Base64 without padding—that's what makes up the three dot-separated parts of a JWT.

Working with Base64 in Practice

In the Browser (JavaScript)

JavaScript has built-in Base64 functions, though they're a bit quirky:

// Encode text to Base64
btoa('Hello World')  // "SGVsbG8gV29ybGQ="

// Decode Base64 to text
atob('SGVsbG8gV29ybGQ=')  // "Hello World"

// For binary/Unicode: use TextEncoder
const bytes = new TextEncoder().encode('Hello 🌍')
const base64 = btoa(String.fromCharCode(...bytes))

The btoa and atob functions only handle ASCII characters, which is why you need the TextEncoder workaround for Unicode text. It's one of those JavaScript quirks that trips up developers constantly.

In the Terminal

# Linux/macOS
echo -n "Hello" | base64          # SGVsbG8=
echo "SGVsbG8=" | base64 --decode # Hello

# Windows PowerShell
[Convert]::ToBase64String(
  [Text.Encoding]::UTF8.GetBytes("Hello")
)  # SGVsbG8=

Encoding Images for Data URIs

Want to embed a small icon directly in your HTML or CSS without a separate file request? You can convert any image to a Base64 data URI using FileMint's Base64 Image Encoder — it runs entirely in your browser so your images stay private.

Performance Considerations

If you're a web developer, here's the practical rule of thumb:

With HTTP/2 and HTTP/3 multiplexing, the cost of additional requests has dropped significantly compared to HTTP/1.1 days. The old advice of "inline everything small" is less compelling than it used to be. But for critical rendering path assets—the favicon, a loading spinner, a key UI icon—inline Base64 can still shave milliseconds off your perceived load time.

The Bottom Line

Base64 is a tool, not a solution. It solves one specific problem: getting binary data through text-only channels. It's not encryption. It's not compression (it does the opposite). And it's not a replacement for proper file hosting.

Use it when you need to embed small binary assets in text contexts. Avoid it when you're dealing with large files, when caching matters, or when you need actual security. And please, for the love of all things good, stop putting passwords in Base64 and calling it "encoded for security."

Need to encode or decode some Base64 right now? Our Base64 Converter handles text and files, runs entirely in your browser, and doesn't send your data anywhere.