Base64: What It Does and What It Isn’t

Base64 is a binary-to-text encoding that represents arbitrary bytes using a 64-character ASCII alphabet, letting binary data travel safely through channels built for text. It is one of the most widely used and most widely misunderstood encodings in software. People reach for it expecting security or smaller payloads and get neither. What Base64 actually gives you is safe transport, at the cost of about a third more size. This article explains the mechanism, the size math, the base64 versus base64url distinction, and why calling Base64 “encryption” is a mistake worth avoiding.

What problem does Base64 actually solve?

Base64 solves the problem of moving binary data through systems that only handle text reliably. Many protocols were designed decades ago for 7-bit ASCII and treat certain byte values specially: a null byte, a newline, or a high-bit character can be stripped, rewritten, or interpreted as a control signal. If you drop a raw JPEG or an encrypted blob into such a channel, it can arrive corrupted.

Base64 sidesteps this by mapping every possible byte value onto a small, safe set of printable characters that virtually every system agrees on: the uppercase letters A to Z, the lowercase a to z, the digits 0 to 9, and two symbols. Because that alphabet has 64 members, each character carries exactly 6 bits of information (2 to the 6th power is 64). The encoder takes the input a few bits at a time and emits one safe character per 6 bits.

You see the result everywhere: email attachments encoded with MIME, images embedded directly in HTML or CSS as data: URIs, binary fields stuffed into JSON, and the segments of a JSON Web Token. In each case the underlying channel wants text, and Base64 is the adapter.

How does the encoding work, byte by byte?

Base64 works on groups of 3 input bytes at a time. Three bytes is 24 bits, and 24 divides evenly into four 6-bit chunks. Each 6-bit chunk becomes an index from 0 to 63 into the alphabet, producing four output characters for every three input bytes.

Consider encoding the three ASCII letters Man, whose byte values are 77, 97, and 110. Written as bits they are 01001101 01100001 01101110. Regroup those same 24 bits into four 6-bit values and you get 19, 22, 5, and 46, which map to the characters T, W, F, and u. So Man encodes to TWFu.

Input:   M        a        n
ASCII:   77       97       110
Bits:    010011  010110  000101  101110
Index:   19      22      5       46
Base64:  T       W       F       u

When the input length is not a multiple of 3, the encoder pads. One leftover byte produces two Base64 characters followed by two = signs; two leftover bytes produce three characters and one =. The equals sign is not part of the data alphabet, it is padding that signals how many bytes the final group really held so the decoder can reconstruct the exact original length.

Why is Base64 output about 33% larger?

Base64 output is larger because it spends 8 bits of output storage to carry only 6 bits of input meaning. Every 3 bytes become 4 bytes, a 4-to-3 ratio, which is a 33.3% increase before you count padding or line breaks. This expansion is inherent to the scheme and is the price you pay for text safety.

Some formats, like classic MIME email, also insert a line break every 76 characters, which adds a small amount on top. The practical takeaway: if you Base64-encode a 5 MB image into a data URI, budget for roughly 6.7 MB of text. That is why inlining large assets bloats HTML and CSS, and why you generally reserve data URIs for small icons.

What is the difference between base64 and base64url?

The difference is two characters in the alphabet plus how padding is handled. Standard Base64, defined for MIME, uses + and / as its 63rd and 64th symbols. Both of those cause trouble in URLs: / is a path separator and + is often interpreted as a space in query strings. The base64url variant swaps them for - and _, which are safe in URLs and in filenames.

This is exactly why JSON Web Tokens use base64url: a JWT has three parts separated by dots, and it must survive being pasted into URLs and HTTP headers. The first 62 alphabet characters are identical in both variants, so short strings can look the same until a + or / appears. If you decode with the wrong variant, those two characters are what break. A good Base64 encoder and decoder lets you pick the variant explicitly so you are not guessing.

Why is Base64 not encryption?

Base64 is not encryption because it involves no key and no secret. Encryption transforms data so that only someone holding the correct key can recover it; Base64 transforms data with a fixed, public algorithm that anyone can reverse in a fraction of a second. There is nothing to know except “this is Base64,” and the padding and alphabet make it trivially recognizable.

Treating Base64 as a security measure is a genuine and recurring mistake. If you Base64-encode a password, an API key, or a session token and consider it “hidden,” you have hidden nothing. Anyone who intercepts the string decodes it instantly. Base64 is obfuscation at best, and weak obfuscation at that, because it announces itself.

This connects directly to a privacy habit worth keeping: because our tools, including the Base64 converter, run entirely in your browser and never send your input to a server, you can safely inspect data locally. But you should still never paste live production secrets into any online tool, ours included, and you should never rely on Base64 to protect anything. When you need confidentiality, use TLS in transit and authenticated encryption at rest. When you need to prove integrity, use a hash or a signature. Base64 is a transport format that sits alongside those tools, not a replacement for them.

Does Base64 compress data?

No, Base64 never compresses; it always expands, by the 33% we calculated above. Compression finds and removes redundancy to make data smaller. Base64 does the opposite, spreading the same information across more characters. The two operations are frequently confused because both are “transformations you run on a blob,” but their goals are opposite.

If your real goal is smaller payloads, compress first with an algorithm like gzip, Brotli, or zstd. If that compressed output then needs to travel through a text-only channel, you Base64-encode the compressed bytes as a final step, accepting the size increase in exchange for safe transport. The correct order matters: compressing after Base64 is nearly useless, because Base64 output is already high-entropy text with little redundancy left to squeeze.

When should you actually use Base64?

Reach for Base64 whenever binary data has to pass through something that expects text. Common, legitimate uses include:

- Embedding a small image inline:  data:image/png;base64,iVBORw0KGg...
- Encoding email attachments (MIME Content-Transfer-Encoding)
- Storing binary in a JSON string field that cannot hold raw bytes
- The header and payload segments of a JWT (base64url, no padding)
- HTTP Basic auth, which base64-encodes "user:password" (over TLS only)

Notice that last example reinforces the security point: HTTP Basic authentication sends your credentials as Base64, which is why it is only acceptable over an encrypted HTTPS connection. The Base64 there is for transport formatting, and the encryption comes entirely from TLS underneath.

Used for what it is, a reliable, universal, reversible text encoding, Base64 is excellent and boring in the best way. Used for what it is not, a shield against prying eyes or a way to shrink files, it fails quietly and sometimes dangerously. Keep the mental model simple: Base64 makes binary data safe to write as text, adds about a third to its size, and keeps no secrets. If you can decode it, so can everyone else, and that is exactly the point.