Base64 is one of those things you use constantly as a developer without thinking much about how it works. You see it in data URIs, API authentication headers, email attachments, and JWT tokens. But what is it actually doing, and why does it exist?
What Base64 does
Base64 is a binary-to-text encoding scheme. It takes arbitrary binary data and represents it using only 64 printable ASCII characters: A-Z, a-z, 0-9, +, and /, with = used for padding.
The process is straightforward: take 3 bytes of binary data (24 bits), split them into 4 groups of 6 bits, and map each 6-bit value to one of the 64 characters. If the input isn’t evenly divisible by 3 bytes, padding characters fill the gap.
The trade-off is size. Base64-encoded data is roughly 33% larger than the original. Three bytes become four characters. This overhead is the cost of ensuring the data is safe to transmit through text-only channels.
Why it exists
Many protocols and systems were designed to handle text, not arbitrary binary data. Email (SMTP) is the classic example — it was built for 7-bit ASCII text. If you wanted to send a PNG attachment through email, you couldn’t just dump raw bytes into the message body. Base64 solved this by encoding binary data into a subset of ASCII that every mail server could handle without corruption.
The same principle applies to JSON (which can’t contain raw binary), URLs (which have reserved characters), XML documents, and HTTP headers. Anywhere binary data needs to travel through a text-based channel, Base64 is a reliable encoding.
Encoding is not encryption
This distinction matters. Base64 is encoding, not encryption. It provides zero security. Anyone can decode Base64 — there’s no key, no secret, no algorithm to break. It’s a reversible transformation, like converting Celsius to Fahrenheit.
If you’ve ever decoded a JWT token and been surprised that the payload is right there in plain text — that’s because the payload is just Base64-encoded JSON. JWTs rely on the signature for integrity, not on hiding the contents.
Don’t use Base64 to “hide” sensitive data. It’s not obfuscation; it’s a formatting step. Anyone with a Base64 decoder can read it instantly.
Common use cases
Data URIs. Embedding small images directly in CSS or HTML avoids an extra HTTP request. You’ll see these as data:image/png;base64,iVBOR.... Good for icons under a few KB; bad for anything large because of the 33% size increase.
HTTP Basic Authentication. The Authorization header uses Base64 to encode username:password. Again, this is encoding for transport, not security — always use HTTPS alongside it.
Email attachments. MIME encoding uses Base64 to package binary files within text-based email messages. This is happening behind the scenes every time you attach a file.
Storing binary data in JSON. Since JSON doesn’t support binary values, Base64 is the standard way to include things like cryptographic keys, certificates, or small binary payloads in JSON structures.
URL-safe variants. Standard Base64 uses + and /, which conflict with URL syntax. Base64url replaces these with - and _ and drops the padding. JWTs use this variant.
Working with Base64
In the terminal, most systems have it built in. On macOS and Linux:
echo -n "hello" | base64encodes a stringecho "aGVsbG8=" | base64 -ddecodes it
In JavaScript, btoa() and atob() handle encoding and decoding, though they only work with Latin-1 characters. For Unicode strings, you need to encode to UTF-8 first using TextEncoder.
For quick encoding and decoding without worrying about edge cases, our Base64 Encoder and Base64 Decoder handle it in the browser. Paste your input, get your output. No data sent to any server.
Base64 isn’t glamorous, but it’s one of those fundamental building blocks of the web that’s worth understanding properly. Once you know what it does (and what it doesn’t), you’ll spot it everywhere.