What Is Base64 Encoding and When Should You Actually Use It

You have already met Base64, you just didn't know it

Pull up the source of almost any web page and you will likely hit a wall of characters starting withdata:image/png;base64,iVBORw0KGgo.... That is Base64. Or you have called an API that ships an image back as one long string instead of a file. Same thing.

It is everywhere in software, and almost nobody can say what it actually does. So let's close that gap. The short version: it is a way to write binary data using only text characters. Understanding the why turns a confusing blob into something you can reason about, like the encoding work our client-side processing guide touches on.

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. The raw numbers, for a few representative file sizes, look like this:

For anything larger than a few hundred bytes the ratio settles right at 33%, give or take the one or two padding characters at the very end. That is the number to plug into your size estimates. The math is fixed inRFC 4648, the spec that defines the encoding.

Base64 is NOT encryption (please stop using it like it is)

This mistake shows up constantly. Someone sees cGFzc3dvcmQxMjM=and figures "nobody can read that, so it's safe." No. Anyone with a browser console, a terminal, or any Base64 decoder turns that back intopassword123 in about two seconds. Encoding is not locking a door. It is writing the password in slightly different ink.

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. Only practical for small data though.

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 Base64btoa('Hello World')  // "SGVsbG8gV29ybGQ=" // Decode Base64 to textatob('SGVsbG8gV29ybGQ=')  // "Hello World" // For binary/Unicode: use TextEncoderconst bytes = new TextEncoder().encode('Hello 🌍')const base64 = btoa(String.fromCharCode(...bytes))

The btoa and atobfunctions 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/macOSecho -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 , which 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, the cost of extra requests dropped a lot compared to the HTTP/1.1 days. The spec lets many requests share one connection through multiplexing (RFC 9113), so the old "inline everything small" advice lost its punch. For a critical above-the-fold icon, an inline data URI can still save a request. For almost everything else, a normal file the browser can cache separately is the better call. The data URI format itself is defined in RFC 2397, and MDN has a plain-language data URL reference.

The bottom line

Base64 is a tool, not a solution. It solves one narrow problem: getting binary data through text-only channels. It is not encryption. It is not compression, it does the opposite. And it is not a stand-in for real file hosting.

Use it to embed small binary assets in text. Avoid it for large files, for anything you want the browser to cache, or for anything you think needs to be secret. And please, stop putting a password in Base64 and calling it "encoded for security." It takes two seconds to reverse. If you want to actually protect data, start with our checksums guide or theMD5 vs SHA-256 comparison.

Need to encode or decode some Base64 right now? Our Base64 Converter handles text and files, runs entirely in your browser, and never sends your data anywhere. For images, theBase64 image encoder does the same job locally.