What Is Base64 and Why Is It Everywhere?
September 29, 2026 · 5 min read
The first time I opened an HTML file and saw data:image/png;base64,iVBORw0KGgoAAAANSUh... stretching on for three screenfuls, I assumed something was broken. It wasn't. That wall of gibberish was an entire image, smuggled inside a text file. The smuggling technique is called Base64, and once you see it, you start noticing it everywhere: email attachments, JWT tokens, API keys, those Authorization: Basic headers. It's one of those things every developer bumps into and nobody properly explains. Let's fix that.
The problem Base64 solves
Computers are great with binary — images, executables, compressed files, all just bytes. But a lot of the internet's plumbing was built for text. Email was designed for text. JSON is text. URLs are text. HTTP headers are text.
So what do you do when you need to push binary data through a text-only channel? You could try sending raw bytes and hope for the best. Sometimes that works. Often it doesn't: old mail servers mangle byte values they don't recognize, a stray null byte terminates a C string early, a byte that looks like a line break splits your data in half. The history of computing is littered with corrupted attachments from exactly this.
Base64's answer is beautifully dumb: take your binary data and re-encode it using only 64 "safe" characters — A–Z, a–z, 0–9, +, and /, plus = for padding. Every one of these survives email, JSON, URLs (mostly), and copy-paste without corruption. The tradeoff: the output is about 33% bigger than the input. That's the price of safety.
How it works (the 30-second version)
Take 3 bytes of input — that's 24 bits. Chop those 24 bits into 4 groups of 6 bits. Each 6-bit group is a number from 0 to 63, and each number maps to one of the 64 safe characters. So every 3 input bytes become exactly 4 output characters. If the input length isn't divisible by 3, you pad with = signs. That's the whole trick. There's no compression, no encryption, no magic — it's just a different way of writing the same bits.
Which brings us to the most common misconception:
Base64 is not encryption
I want to be blunt about this because people get burned: Base64 provides zero security. Anyone can decode it instantly — it's as "secret" as writing a message backwards. If you see credentials or tokens Base64-encoded in a config file or a URL, treat them as plain text. Real protection means actual encryption (TLS, AES, etc.), not encoding.
What Base64 is good for is transport. It's a packaging format, like putting a fragile vase in a padded box. The box doesn't lock anything; it just gets the vase there intact.
Where you'll actually run into it
- Data URLs.
<img src="data:image/png;base64,...">embeds a small image directly in HTML or CSS. Handy for tiny icons; terrible idea for a 4 MB photo (remember the 33% overhead, and it can't be cached separately). - Email attachments. MIME emails encode attachments in Base64. That PDF your grandma sent? Base64 under the hood.
- JWTs and API tokens. A JSON Web Token is three Base64-encoded chunks joined by dots. You can paste one into a decoder and read the payload — which is exactly why you should never put secrets in a JWT payload.
- Basic auth headers.
Authorization: Basic dXNlcjpwYXNzis justuser:passin Base64. Again: not encryption. Never use basic auth without HTTPS. - Embedding binary in JSON/XML. APIs that need to return a file inside a JSON response usually Base64 it.
Variants worth knowing
Standard Base64 uses + and /, which are both meaningful in URLs (+ means space in query strings, / separates paths). So there's a URL-safe variant that swaps them for - and _ and often drops the padding. If you're putting Base64 in a URL and something looks off, check which variant you're dealing with — mixing them up is a classic half-hour-debugging-session starter.
Try it yourself
The fastest way to build intuition is to play with it: encode your name, decode a JWT payload, watch how 3 bytes become 4 characters.