DEV Community

Mike Knights
Mike Knights

Posted on • Originally published at datatoolkit.net

Base64 is not encryption - here's what it actually does

Base64 comes up constantly - in JWTs, email attachments, data URIs, API payloads. Most developers have used it dozens of times. But a surprising number have a slightly wrong mental model, and that leads to misuse.

The biggest mistake: treating it as a form of obfuscation or lightweight encryption. It isn't.

What it actually does

Base64 takes binary data and converts it into a string of 64 printable ASCII characters (A-Z, a-z, 0-9, +, /). The original data is completely recoverable with no key required. Anyone who sees the output can decode it in seconds.

The reason it exists has nothing to do with security. Many systems that transport text - email, HTTP headers, JSON, HTML attributes - were never designed to handle arbitrary binary data. If you embed raw binary in those systems, you get corruption or parsing errors. Base64 gives binary a safe disguise for the journey.

Where you run into it

JWTs. A JSON Web Token is three Base64url-encoded sections separated by dots. The header and payload are just encoded JSON - paste either into a Base64 decoder and you can read them in plain text. The only security comes from the signature at the end, not the encoding. Don't put sensitive data in a JWT payload unless you're encrypting it separately.

HTTP Basic Auth. The Authorization: Basic header is username:password Base64-encoded. It looks obscure, but it isn't. HTTPS is what protects it in transit.

Data URIs. data:image/png;base64,... in HTML or CSS is the image file encoded inline. Fine for small icons, bad idea for anything large.

Email attachments. SMTP was built for plain text. Attachments are Base64-encoded inside the message body so binary files survive.

The padding thing

The = characters at the end aren't significant - they're padding to make the output length a multiple of 4. Base64url (used in JWTs and URLs) drops the padding entirely and replaces + with - and / with _ so the output is URL-safe. Same data, different alphabet.

When to use it

When you need to move binary data through a system that only speaks text. That's it. Not for hiding data, not for security, not as a step in encryption (unless you're encoding the output of actual encryption).

If you want to encode or decode something quickly in the browser - nothing leaves your device - datatoolkit.net/base64 does it client-side. There's also a longer explanation of how the encoding works mechanically if you want the full picture.

Top comments (0)