How Base64 Encoding Works (and Why It's Not Encryption)

What Base64 actually does at the bit level

Base64 converts 3 bytes of input into 4 output characters by re-slicing 24 bits into four groups of 6 bits each. A byte holds 8 bits, so three bytes give 24 bits; 24 divides evenly by 6, producing four 6-bit numbers ranging from 0 to 63. Each of those numbers indexes into a 64-character alphabet: A-Z (0-25), a-z (26-51), 0-9 (52-61), and two symbols for 62 and 63.

Take the three ASCII bytes for "Man": M=77, a=97, n=110, which in binary are 01001101 01100001 01101110. Concatenated, that 24-bit string re-groups as 010011 010110 000101 101110, or the decimal values 19, 22, 5, 46. Indexing the alphabet gives T, W, F, u, so "Man" encodes to "TWFu". The transformation is purely mechanical and lossless.

The 33% overhead is the defining statistic of the format: 4 output bytes for every 3 input bytes is a 4/3 ratio, a 33.3% increase before any line-break padding. Standard MIME encoding adds a further small penalty by inserting a line break every 76 characters, nudging real-world overhead slightly above 33%.

Why Base64 is NOT encryption or security

Base64 is an encoding, not encryption, because it uses no key and anyone can decode it instantly with a public, standardized algorithm. Encryption transforms data so that only a holder of the correct key can recover it; Base64 transforms data so that any device on earth can recover it, which is the exact opposite goal. Treating a Base64 string as a secret is a classic security mistake.

The confusion arises because Base64 output looks unreadable to humans, all letters and digits with the occasional +, /, or =. But unreadable-to-a-human is not the same as protected. A single command such as `base64 -d` on the command line, or a two-line snippet in any language, returns the original bytes with no credentials required.

The rule to remember: never store passwords, API keys, tokens, or personal data in Base64 thinking it hides anything. Base64 makes binary data safe to transport through text-only channels; it makes nothing safe from prying eyes. If you need confidentiality, you need real encryption such as AES, applied before you Base64-encode the ciphertext for transport.

The = padding, +/ characters, and the Base64URL variant

The = character is padding that signals how many bytes the final group was short, and it appears only at the very end of a Base64 string. When the input length is not a multiple of 3, the last group holds 1 or 2 bytes instead of 3; the encoder pads the missing bits with zeros and appends one = (for a 2-byte remainder) or two == (for a 1-byte remainder) so the output length stays a clean multiple of 4.

Standard Base64 uses + and / for values 62 and 63, but those characters are unsafe in URLs and filenames: + can be interpreted as a space in query strings, and / is a path separator. Base64URL, defined in RFC 4648, swaps them for - and _ respectively, and usually omits the = padding, so a token can travel inside a URL or filename untouched. JSON Web Tokens use Base64URL for exactly this reason.

The table below compares the three variants you will encounter in practice.

When to use Base64 and when not to

Use Base64 whenever binary data must pass through a channel that only reliably carries text: inline images as data URIs in CSS or HTML, binary blobs embedded in JSON payloads, email attachments, and the encoded segments of JSON Web Tokens. In each case the alternative, sending raw bytes, would be corrupted or rejected by systems that assume text.

Avoid Base64 for large files, because the 33% size penalty is paid on every byte. Encoding a 10 MB image produces roughly 13.3 MB of text, which then must be transferred, parsed, and decoded. For anything sizable, send the raw file over a binary-safe transport such as a normal multipart upload or a signed URL, and reserve Base64 for small assets, icons, and metadata.

A second cost is CPU and memory: encoding and decoding large strings is not free, and inlining big data URIs prevents browser caching, since the bytes are re-downloaded with every page that embeds them rather than cached once as a separate file.

Is it safe to encode files privately in the browser?

Yes, Base64 encoding in a modern web tool happens entirely locally in your browser, so your file's bytes are never uploaded to any server. Encoding is pure math, `btoa()` and the FileReader API run on your own device, which means a client-side tool can convert a document or image to Base64 without a network round trip.

This matters when the input is sensitive, a private key, an internal document, a customer image, because a purely client-side encoder gives you the convenience of a web interface with the privacy of an offline command-line tool. Nothing leaves the machine you are working on.

Frequently asked questions