What Is Base64 Encoding? A Plain-English Explanation

If you've ever peeked at the raw source of an email, you've probably seen blocks of random-looking characters — long strings of letters, numbers, slashes, and plus signs that don't resemble anything readable. That's Base64. It shows up all over the place in software, but most people encounter it without knowing what it is or why it's there.

Base64 isn't encryption. It's not compression. It's a way of representing binary data (like images, files, or any raw bytes) using only plain text characters. And once you understand why that matters, you'll start noticing it everywhere.

What Base64 Actually Is

Base64 is an encoding scheme that converts binary data into a string of 64 specific ASCII characters. Those 64 characters are: A-Z (26), a-z (26), 0-9 (10), plus (+) and slash (/). That's it. Some variants swap out those last two characters, but the idea is always the same: represent arbitrary bytes using only characters that are safe to send through text-based systems.

The name "Base64" comes from the fact that it uses 64 characters as its alphabet. Compare that to Base10 (decimal, the numbers 0-9 we use daily) or Base16 (hexadecimal, which uses 0-9 and A-F). Base64 just has a bigger alphabet, which means it can pack more information into fewer characters than hex can.

A quick example: the text "Hello" in Base64 becomes SGVsbG8=. The trailing equals sign is padding. It fills out the output to a multiple of 4 characters. You'll often see one or two equals signs at the end of Base64 strings.

Why Base64 Exists

Here's the problem Base64 solves. Many protocols and systems were designed to handle text, not raw binary data. Email is the classic example. SMTP, the protocol that sends email, was built in the early 1980s to carry 7-bit ASCII text. That's 128 possible characters. But a JPEG image or a PDF file uses all 256 possible byte values (8-bit data), including control characters that would confuse or break text-based protocols.

You can't just paste raw binary into an email and hope for the best. Some bytes would be interpreted as protocol commands. Others would get silently stripped or modified. The message would arrive corrupted.

Base64 fixes this by translating every 3 bytes of binary data into 4 characters that are guaranteed safe for text transmission. The trade-off is size: Base64 output is about 33% larger than the original binary data. Three bytes become four characters, so a 1 MB file becomes roughly 1.33 MB when Base64-encoded. That overhead is usually worth it for the guarantee that the data arrives intact.

How the Encoding Works

The encoding process is surprisingly simple once you see it step by step.

Take 3 bytes of input data. That's 24 bits. Split those 24 bits into four groups of 6 bits each. Each 6-bit group can represent a number from 0 to 63, and each of those numbers maps to one of the 64 characters in the Base64 alphabet. So 3 bytes in, 4 characters out.

What happens when the input isn't a multiple of 3 bytes? That's where padding comes in. If there's 1 byte left over, it gets encoded as 2 characters plus ==. If there are 2 bytes left over, you get 3 characters plus =. The equals signs tell the decoder how many bytes to expect at the end.

Let's trace through the letter "M" (which is byte value 77, or 01001101 in binary). Since it's just 1 byte, we pad it to 12 bits: 010011 010000. The first group (010011) is decimal 19, which maps to "T". The second group (010000) is decimal 16, which maps to "Q". Add two padding characters, and "M" becomes TQ==.

You can try this yourself with our Base64 encoder/decoder. Paste in any text and see the encoded output instantly.

Email Attachments and MIME

Email attachments are probably the most widespread use of Base64 on the internet. Every time you attach a photo or document to an email, your email client Base64-encodes it before sending. The receiving client decodes it back to the original file.

This happens through MIME (Multipurpose Internet Mail Extensions), a standard from 1996 that extended email to support non-text content. When you look at a raw email with an attachment, you'll see a MIME header like Content-Transfer-Encoding: base64 followed by a wall of Base64 text. That wall of text IS your attachment — just encoded as safe ASCII characters.

Gmail, Outlook, Yahoo Mail: they all do this behind the scenes. The billions of emails sent daily contain enormous amounts of Base64-encoded data. It's one of those invisible pieces of infrastructure that quietly makes modern communication work.

Data URIs in Web Development

Web developers run into Base64 constantly through data URIs. A data URI lets you embed file content directly in HTML or CSS instead of linking to a separate file. They look like this:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...

That string IS the image. The browser decodes the Base64 and renders it, so no separate HTTP request is needed. This is handy for small images like icons, tiny logos, or 1-pixel tracking pixels. Instead of making the browser fetch a separate file from the server, the image data is right there in the HTML.

CSS files use this trick a lot for background images. You'll see something like background-image: url(data:image/svg+xml;base64,...) to embed an SVG directly in a stylesheet. It eliminates a network request, which can speed up page rendering.

But there's a catch. Remember that 33% size overhead? For small files (under a few KB), the overhead is negligible and you save an HTTP request. For larger files, you're actually making things worse. A 50 KB image becomes 67 KB of Base64 text, and it can't be cached separately from the HTML or CSS file it's embedded in. The general rule: use data URIs for files under about 5 KB, and regular file links for anything bigger.

When Not to Use Base64

Base64 is not encryption. This is worth repeating because people get it wrong all the time. Encoding something in Base64 doesn't protect it at all. Anyone can decode it instantly — there's no key, no secret, nothing preventing someone from reversing it. If you need to protect data, use actual encryption. Base64 just changes the representation; it doesn't hide anything.

Don't use Base64 to store large files in databases. Some developers encode images as Base64 strings and stuff them into text columns. This works but it's almost always a bad idea. The data is 33% bigger, queries become slower, and you lose the ability to serve files with proper caching headers. Store files as actual files (or binary blobs) and serve them normally.

Don't use Base64 for data that's already text. If you're sending a JSON payload over HTTP, there's no reason to Base64-encode it first. HTTP handles text just fine. Base64 only makes sense when you need to push binary data through a channel that only supports text.

Common Base64 Patterns You'll See

Once you know what Base64 looks like, you'll spot it constantly. Here are the most common places it shows up:

JWTs (JSON Web Tokens). Those long strings used for authentication in web apps? They're three Base64-encoded segments separated by dots. The first segment is a header, the second is the payload (containing user info and claims), and the third is a cryptographic signature. You can decode the first two parts to see exactly what data they carry.

API authentication. HTTP Basic Authentication sends your username and password as a Base64-encoded string in the Authorization header. Again, this is encoding, not encryption. Without HTTPS, anyone watching the network traffic can decode your credentials instantly.

SSL certificates. Open a .pem certificate file and you'll see Base64 text between "BEGIN CERTIFICATE" and "END CERTIFICATE" markers. The actual certificate data is binary (DER format), and Base64 makes it safe to paste into config files and transmit over text protocols.

Git and source control. Binary files in diffs and patches often show up as Base64. Git's internal format handles binary natively, but when patches are shared as text (like in emails or pull requests), binary content gets Base64-encoded.

Base64 has been around since the 1980s and isn't going anywhere. It does one thing — makes binary data safe for text channels, and it does it reliably. Next time you see a suspicious-looking string ending in "==" in a config file or API response, you'll know exactly what you're looking at.

Want to encode or decode something right now? Try our Base64 Encoder/Decoder. And if you're working with API responses, our JSON Formatter can help you make sense of the decoded output. For securing your API keys and tokens, check out the Password Generator.