Base64 Is Encoding, Not Encryption

Base64 appears in data URIs, JWTs, email attachments, API payloads and private-key files, and it is the single most misunderstood notation in everyday programming — mostly because people see U3dvcmQ= and assume something protective happened. Nothing was protected. Base64 is a alphabet-translation step with a closed-form length formula, and you can reverse it in your head once you know the rules.

What the algorithm does

Binary data is bytes: 8 bits each. Some transport layers were built for text and mangle bytes that are not printable ASCII. Base64 fixes that by re-cutting the same bit stream into 6-bit groups, because 2^6 = 64 and 64 printable characters were chosen to be safe almost everywhere. Three bytes (24 bits) therefore become exactly four 6-bit groups, and each group indexes a 64-character alphabet. That is the entire idea; the padding character = only records that the last group was short.

The standard alphabet is A–Z, a–z, 0–9, then + and /. Index 0 is A, index 26 is a, index 52 is 0, index 62 is +, index 63 is /.

A worked example, byte by byte

Take the three characters Man. Their bytes are 77, 97, 110. Laid end to end that is 24 bits, split into four 6-bit numbers:

Concatenated, that is TWFu — which is exactly what Buffer.from(“Man”).toString(“base64”) returns. Nothing was hidden: the mapping is a lookup, and a lookup with a published alphabet has no key.

Why the output length is predictable

Because 3 bytes always become 4 characters, an n-byte input always produces ceil(n/3)×4 characters, with (3 − n mod 3) mod 3 padding signs. So you can tell how big the original file was from the length of the blob alone — another reason it is encoding rather than encryption:

The asymptotic cost is 33.33% — four-thirds of the original. On a 100-byte payload the measured increase is 36% because padding lands at the end. This is why base64 is a poor choice for storing large binaries in a database column and a perfectly reasonable one inside JSON, where the alternative is worse.

The UTF-8 trap that bites everyone once

Base64 operates on bytes, so the first question is always “bytes of what?”. In JavaScript the classic pair btoa and atob is defined over Latin-1 code units, not UTF-8. Feed it anything outside that range and it refuses outright — on the runtime used for this page, btoa(“naïve café — 日本語”) throws DOMException: Invalid character.

The correct route is to convert to UTF-8 bytes first, then encode. Same string, three different answers depending on what you assumed:

Round-tripping the UTF-8 form returns the original string exactly (verified), which is the property you want. The encoder on this site does the UTF-8 conversion with TextEncoder and TextDecoder rather than btoa, so non-ASCII input survives the trip.

URL-safe Base64, and why the padding disappears

Two characters in the standard alphabet are hostile inside URLs: + is read as a space in query strings and / looks like a path separator. Base64url swaps them for - and _, and most implementations also drop the = padding, since the length already determines how many bytes were missing. Three bytes chosen to force both symbols, 0xfb 0xff 0xbe, encode as:

This is what you are looking at in a JWT: three base64url segments separated by dots, and — this surprises people the first time — the header and payload are simply JSON, so decoding a token you were given reveals its claims immediately. A JWT’s security comes from the signature on the third segment, never from the encoding of the first two.

Where you actually meet it

• Data URIs — images inlined into CSS or HTML. The ;base64, marker is the only clue.
• Email — MIME Content-Transfer-Encoding: base64 for attachments, which is exactly the “text-only transport” problem the format was designed for.
• HTTP Basic auth — the browser sends Authorization: Basic base64(user:password). Anyone on the path can undo it in one step, which is why Basic over plain HTTP is a bug report, not a design.
• Private keys and certificates — PEM is base64 of DER between the BEGIN/END lines.
• APIs and JSON — binary fields smuggled through a text format, including protobuf and gRPC-Web envelopes.

So when is it not reversible?

Never, without extra machinery. If you need one-way, that is a hash — and note that a hash is not secret either, it is only irreversible in practice for a good function and a non-guessable input; a common password hashed with SHA-256 and not salted is a few seconds of GPU work. If you need confidentiality, encrypt first and encode the ciphertext afterwards, in that order. Base64’s job is to survive a text-only pipe, and it does that job well; treating it as a security layer is the mistake.

Frequently asked questions

Related tools

Written and maintained by CHENYUWEN. First published 2026-10-30. If something here is wrong, tell us - corrections are dated on the page.