Base64 is encoding, not encryption: what that jumble actually is

The strings look like codes: SGVsbG8=, eyJhbGciOiJIUzI1NiJ9, dG9vbGl2YXJv. Loads of characters, padding with an equals sign, zero recognizability — a reasonable person glances at them and assumes a secret is involved. It is not. These are encodings, and the difference between encoding and encryption is the difference between a costume and a lock. This page explains the costume — how Base64 works, what it is for, and the one question that separates “text-safe” from “secret”.

What encoding means

Encoding is a translation between representations, governed by a public, reversible rule. The most familiar example is not technical at all: Morse code. Dots and dashes are not a secret — anyone with the table can read them — but they let a telegraph channel carry letters it could not otherwise transmit. Base64 is the same idea for bytes: it is a fixed, published mapping from binary data to a 64-character alphabet, designed so that data which only speaks text can carry binary payloads.

The alphabet is the giveaway that nothing is hidden: A–Z, a–z, 0–9, +, /, plus = for padding. Every character in a Base64 string is one of these 64, and the mapping is public in every implementation of every language. A decoder needs no key, no password, no negotiation — just the string. That is the defining difference: encryption scrambles data with a secret, and the result is useless without it; encoding reshapes data with a public rule, and the result is readable by anyone who knows the rule — which is everyone.

The mechanics, in one example

Base64 works in groups of three bytes. Three bytes are 24 bits; 24 bits divide evenly into four 6-bit groups; each 6-bit group selects one of the 64 alphabet characters. Three bytes in, four characters out.

Take the word “Hello” — five bytes:

Step	Value
Text	H e l l o
Bytes (ASCII)	72 101 108 108 111
Bit stream	01001000 01100101 01101100 01101100 01101111
6-bit groups → alphabet	SGVsbG8
Padding to a multiple of 4	SGVsbG8=

The trailing = pads the final group: five bytes are not a multiple of three, so the last group holds two bytes and one padding character completes it. Every Base64 string is a multiple of four characters, and the = appears only at the end — which is also the first validity check: a Base64 string with padding in the middle, stray characters, or a length not divisible by four is malformed, and an honest decoder rejects it with a reason rather than manufacturing output.

The price: 33% overhead

The three-to-four mapping has a fixed cost: the encoded form is always one third larger than the bytes it represents — a 6 MB file becomes 8 MB of Base64 text, plus up to two padding characters. That overhead is the toll for crossing a text-only channel. The places it is worth paying:

• Email attachments. MIME encodes attachments as Base64 because the original email protocols carried text only; your image arrived as a long, harmless-looking string that the mail client decoded on your behalf.
• Embedding data in URLs or JSON. A small binary payload — a thumbnail, a public key, an icon — can be inlined as a Base64 string in a data: URL or a JSON field, traveling where raw bytes cannot.
• Tokens. JWTs and similar tokens base64-encode their three parts (header, payload, signature) into the familiar eyJ… form. The format is text-friendly by design.

Notice what the third use case does not say: the encoding provides no security whatsoever.

The JWT example: readable in seconds

Take a JWT’s payload — the middle part of a token. It is Base64 of a small JSON document, and decoding it takes one paste into any decoder:

eyJzdWIiOiIxMjM0NTY3ODkwIn0 → {"sub":"1234567890"}

That is the entire story of the “cipher”: the token’s payload is meant to be read by its recipient — the security of the token lives in the third part, the signature, which is computed with a secret key and verified cryptographically. Base64 is the envelope, not the lock. Anyone who can view the token can read the payload; the signature is what prevents anyone from changing it. If you ever hear “it’s safe, it’s Base64-encoded”, the correct response is “Base64-encoded to whom?” — because the answer is always “to anyone who can see it.”

The sibling: percent-encoding

The same costume appears in URLs. Percent-encoding (URL encoding) maps each byte that would be misread as structure into a %-sequence: a space becomes %20, a question mark %3F, é (two bytes in UTF-8) becomes %C3%A9. It exists so arbitrary text — search terms, tokens, filenames — can ride inside a URL without breaking it. Like Base64, it is fully reversible by anyone, and like Base64, the exact escaping rules matter: a query value is escaped with the component rules (which escape : / ? & = as well), while a whole URL deliberately leaves those characters alone. Encoders that blur the two produce links that break — one more reason to use a tool that is explicit about which function it runs, rather than one that guesses.

Both encodings share one honest property worth keeping: they are deterministic and verifiable. If you know the input, you can predict the output and check the tool’s work — which is exactly what the calculators below do, by showing the byte-level steps rather than just the answer.

Let the calculator do it

The Base64 encoder/decoder works with text and files in both directions, with byte-accurate statistics (input size, output size, and the encoding overhead), strict RFC 4648 validation that rejects malformed strings with a reason, and correct UTF-8 handling — binary payloads decode to a downloadable file rather than being mangled into text. The URL encoder/decoder performs percent-encoding with exactly the encodeURIComponent semantics of every browser and Node.js, documenting the difference from whole-URL encoding so the round trip is lossless. Both run entirely on your device — nothing is uploaded, logged, or stored, which matters when the string you are inspecting is a token or a signed URL.

The one rule

Ask “would a decoder work without a key?” — if yes, it is encoding, and the data is visible to anyone who has it. Base64 makes bytes text-safe; it hides nothing, protects nothing, and is reversed in milliseconds by free tools. The moment you want actual secrecy, you need encryption — and the only place encryption belongs in this workflow is a real cryptographic library with a managed key, never a string transformation in a web form.