Base64 in the Wild: 5 Places You Use It Every Day Without Knowing

I was debugging a broken email template last week and found the culprit: a Base64-encoded image in the HTML that had a single character missing from the end. One character. The entire image was just a broken icon. That's the thing about Base64 — it's invisible when it works and catastrophic when it doesn't.

Most developers think of Base64 as that thing you use occasionally to encode API credentials. But it's actually everywhere. If you've sent an email, loaded a webpage, logged into an app, or shared a file today, you've interacted with Base64 at least a dozen times. Let me show you where.

What Base64 Actually Does

Quick primer for anyone who's fuzzy on the details: Base64 converts binary data into ASCII text. It takes 3 bytes of binary data (24 bits) and encodes them as 4 ASCII characters. The "64" comes from the character set used: A-Z, a-z, 0-9, +, and / (with = as padding).

Why does this exist? Because many systems were designed to handle text, not binary data. Email servers, HTML parsers, JSON parsers, URL schemes — they all expect printable ASCII characters. Binary data (like images, encrypted tokens, or compressed files) can contain bytes that look like control characters to these systems, causing corruption or truncation.

Base64 ensures that any data, no matter how binary, can survive transport through text-only channels. It's not encryption, it's not compression — it's just a translation layer. And it's everywhere.

1. Email Attachments (MIME Encoding)

Every email you've ever sent with an attachment has used Base64. The MIME standard (Multipurpose Internet Mail Extensions) encodes all non-text attachments as Base64 before transmission. Your email client does this automatically — you attach a PDF, it gets Base64-encoded, sent across SMTP servers as text, and decoded by the recipient's email client.

This was the original use case for Base64 in computing. SMTP (the email protocol) was designed in 1982 to handle 7-bit ASCII text only. Binary attachments would corrupt during transmission because SMTP servers might interpret certain byte sequences as control commands. Base64 solved this by converting binary attachments to safe ASCII characters.

The cost: Base64 encoding increases data size by about 33%. A 3MB PDF attachment becomes a 4MB email payload. That's the tradeoff for compatibility. In the age of gigabit internet, it barely matters for most emails, but it's still a significant overhead for large attachments.

Fun fact: some early email systems would truncate lines at 76 characters because of limitations in older SMTP implementations. Base64-encoded text in emails still follows this 76-character line wrapping convention, even though modern servers don't need it. Backward compatibility is a beautiful and terrible thing.

2. Data URIs in HTML and CSS

Have you ever seen an image tag that looks like <img src="data:image/png;base64,iVBOR..." />? That's a Data URI — an image encoded directly into the HTML as a Base64 string. No separate file download required.

Data URIs were popular for small assets like icons and sprites because they eliminated an HTTP request. Instead of downloading an icon sprite sheet separately, you could embed the icon right in the CSS. One fewer request, slightly faster page load.

The problem: Base64-encoded images are about 33% larger than the original binary file, they can't be cached by the browser independently (they're part of the HTML/CSS), and they make your source code unreadable. A single 50KB icon turns into 67KB of Base64 text sitting in the middle of your stylesheet.

In 2026, Data URIs for images are mostly an anti-pattern. HTTP/2 multiplexing eliminated the request overhead that Data URIs were trying to solve, and modern bundlers handle asset optimization far better than manual Base64 embedding. But you still see them in email templates (where external images are often blocked), in SVGs embedded in HTML, and in legacy codebases that haven't been updated.

3. JSON Web Tokens (JWT)

If you've built or used any modern web API, you've dealt with JWTs. Those long strings with two dots — eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.signature — are Base64-encoded JSON objects.

The header (eyJhbGciOiJIUzI1NiJ9) is a Base64-encoded JSON object specifying the algorithm. The payload (eyJzdWIiOiIxMjM0NTY3ODkwIn0) is a Base64-encoded JSON object containing the claims (user ID, expiration, etc.). The signature is a cryptographic hash that verifies the token hasn't been tampered with.

Here's what trips people up: Base64 is encoding, not encryption. Anyone can decode a JWT payload by simply Base64-decoding it. It's literally just JSON in a different format. A JWT is not a way to hide data — it's a way to verify that data hasn't been modified. The signature proves authenticity, but the payload is readable by anyone who intercepts the token.

I've seen developers put sensitive data (SSNs, API keys, internal IDs) in JWT payloads because they assumed the encoding made it private. It doesn't. If you wouldn't put it in plaintext, don't put it in a JWT.

Also, JWT payloads can get large. A token with lots of claims might be several kilobytes, which means every API request carries that overhead in the Authorization header. Some teams trim their JWTs by removing unnecessary claims, which can have real performance benefits at scale.

4. HTTP Basic Authentication

When you see a browser prompt asking for username and password to access a website, that's HTTP Basic Authentication. Under the hood, the browser concatenates the username and password with a colon (username:password) and Base64-encodes the result before sending it in the Authorization header.

The header looks like: Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Again, this is not encryption. Decoding dXNlcm5hbWU6cGFzc3dvcmQ= gives you username:password in plaintext. Anyone who intercepts the request can read the credentials. That's why Basic Auth should only be used over HTTPS — the TLS encryption protects the Base64-encoded credentials during transit.

Basic Auth is still common in internal APIs, development environments, and simple integrations. It's simple to implement, universally supported, and fine for low-security contexts. But it's a disaster waiting to happen over unencrypted HTTP, and I still see people making that mistake.

5. Source Maps and Inline Assets

If you've ever looked at a minified JavaScript file and seen a comment at the end that starts with //# sourceMappingURL=data:application/json;base64,, that's a Base64-encoded source map embedded directly in the JS file.

Source maps tell the browser how to map minified/compiled code back to the original source files for debugging. Embedding them as Base64 in the file itself means the browser doesn't need to make a separate request for the map file. It's convenient for development, but you should never ship this to production — source maps can expose your original source code to anyone who opens DevTools.

Similarly, some build tools embed small assets (fonts, icons, CSS) as Base64 strings directly in JavaScript bundles. Webpack's asset/source loader and Vite's similar functionality do this automatically for files below a size threshold. It reduces HTTP requests but increases bundle size by 33%, so the threshold needs to be set carefully.

When Base64 Becomes a Problem

Base64 is a useful tool, but it's often misapplied. Here are the situations where it causes more trouble than it solves:

Large file encoding: Base64 adds 33% overhead. For a 1MB image, that's 330KB of extra data. For a 100MB video, it's 33MB. At scale, this overhead is significant. Don't Base64-encode large files when you could just serve them directly.

Security theater: Base64 is not encryption. I've seen API keys, passwords, and personal data "protected" by Base64 encoding, which provides zero security. If you need to protect data, use actual encryption (AES, RSA, etc.), not encoding.

Database storage: Some developers store Base64-encoded images directly in databases instead of using file storage. This bloats the database, prevents CDN caching, and makes backups slower. Store files in object storage and keep the URL in the database.

Performance-sensitive contexts: Base64 encoding and decoding have CPU costs. In a high-throughput API that processes thousands of requests per second, the overhead of constant Base64 operations can add up. Profile before you optimize, but be aware it's not free.

The 33% Tax

Every time you Base64-encode something, you pay a 33% size tax. This is fundamental to how the encoding works: 3 bytes become 4 characters. There's no way around it.

In some contexts, this doesn't matter. A 256-byte JWT payload becoming 340 bytes is negligible. But in other contexts, it adds up quickly. A page with 20 Base64-encoded icons that could be served as a sprite sheet is loading 33% more image data than necessary. An email with a 10MB attachment is consuming 13.3MB of bandwidth.

The question to always ask: "Do I need this data to be text, or could I serve it as binary?" If the answer is that binary would work fine (and it usually does for modern systems), skip the Base64.

The Takeaway

Base64 is a translation layer, not a feature. It exists to solve the problem of binary data in text-only channels, and it does that job reliably. But it's not free — there's a 33% size overhead, a CPU cost for encoding/decoding, and a persistent misconception that it provides security.

Understanding where Base64 appears in your daily workflow helps you debug faster (that broken image? check the Base64 encoding) and make better architectural decisions (don't embed images in HTML, don't store Base64 in databases, don't confuse encoding with encryption).

If you need to encode or decode Base64 quickly, I built a Base64 encoder/decoder that handles text, files, and URLs. It also detects common encoding issues like missing padding, line breaks in the middle of encoded strings, and URL-safe Base64 variants. Faster than opening a terminal every time.