Skip to content
2xKit

Base64 Encoding Explained: It's Not Encryption

Why Base64 turns binary data into text, and why anyone can decode it in seconds despite it looking scrambled.

Quick answer

Base64 is an encoding scheme that converts binary data into plain text using only 64 safe characters (A-Z, a-z, 0-9, +, /), so it can travel safely through systems built for text, like JSON, email, or URLs, but it provides zero security since anyone can decode it back to the original data instantly with no key required. Try it yourself with the Base64 Converter.

Base64 exists to solve a plumbing problem, not a security problem: many older systems, protocols, and text-based formats (email, JSON, XML, URLs) were built to safely carry text but can mangle raw binary data like images or file bytes. Base64 encodes any binary data using only 64 characters that are guaranteed safe everywhere: uppercase and lowercase letters, digits, and two symbols (usually `+` and `/`), so the encoded result can pass through text-only pipes without corruption.

How it actually works

Base64 takes the input data 3 bytes (24 bits) at a time and repackages those 24 bits into four 6-bit chunks, since 6 bits is enough to represent 64 distinct values (2^6 = 64), each chunk maps to one of the 64 safe characters. This is why Base64-encoded output is always about 33% larger than the original data, three input bytes always become four output characters, a fixed and predictable expansion ratio.

Because the mapping between input bytes and output characters is a fixed, publicly known table with no secret key involved, decoding is exactly as easy as encoding, run the Base64 Converter in reverse and you get the original bytes back instantly. There's no password, no key, and no computational difficulty involved anywhere in the process.

Why it's not encryption

Encryption is designed so that only someone holding the correct key can recover the original data, that's the entire point. Base64 has no key at all, it's a public, reversible transformation that anyone, including an attacker, can undo instantly using any decoder, including a one-line command or a website. Storing a password or API key as Base64 text and treating it as "encoded, so it's safe" is a common and serious mistake, it's exactly as readable as if it were stored in plain text, just visually scrambled enough to look secure to someone unfamiliar with the format.

If you actually need to protect the confidentiality of data, that's a job for encryption or, for things like passwords, one-way hashing, not Base64. If you specifically need to verify that a file hasn't been altered rather than hide its contents, tools like Compare File Hashes or the Hash Generator are the right category of tool.

Where Base64 is genuinely the right tool

Base64 is exactly right for embedding small images directly inside CSS or HTML as data URIs, attaching binary files to email (MIME uses Base64 under the hood), and packing binary values into JSON fields, JSON strings can't contain raw binary bytes, so an image or file blob has to be Base64-encoded first, moved as text, then decoded back on the other end. It's also common inside JWT tokens, where the header and payload segments are Base64URL-encoded, a variant that swaps `+` and `/` for URL-safe characters, again purely for safe transport, not for hiding the contents.

Frequently asked questions