Base64 is not encryption (encoding, encryption and hashing, untangled)

cGFzc3dvcmQxMjM= looks secret. It is password123 in Base64, and “decoding” it requires no key, no password and no skill — just any Base64 decoder, including the one on this site. Yet data dressed up this way regularly gets treated as protected, because encoding, encryption and hashing all produce unreadable strings, and the three get mentally filed together.

They guarantee entirely different things. Here is the sorting.

Encoding: a change of alphabet

Encoding transforms data so it survives transport. Base64 exists because many channels — email headers, URLs, JSON strings, XML — handle only text, and binary data (images, ciphertext, arbitrary bytes) would be corrupted passing through them. Base64 re-writes any bytes using 64 safe characters (A–Z, a–z, 0–9, +, /), at the cost of 33% size growth: every 3 bytes become 4 characters.

The defining property: reversal requires nothing secret. The algorithm is public and parameter-free; decoding is mechanical. Encoding provides zero confidentiality — it is a shipping container, not a safe. The same is true of URL encoding (%20 for a space) and HTML entities (&): all transport formats, all trivially reversible by design.

The = padding at the end of many Base64 strings is a length marker, not a lock — it pads the output to a multiple of four characters.

Encryption: secrecy with a key

Encryption transforms data so only key-holders can read it. The algorithm can be completely public — AES is standardised and open — because security rests entirely on the key. Without it, ciphertext is unreadable in any practical sense; with it, decryption is exact.

The defining property: reversible, but only with the key. That makes encryption the right tool whenever data must be hidden from some parties and readable by others: disk encryption, HTTPS traffic, password managers, sealed messages.

The give-away difference from encoding: encryption has keys to manage, and that key management — generating, storing, sharing them — is where all the real difficulty lives. Any “encryption” that needs no key from you is either encoding in disguise or key management hidden somewhere else.

Hashing: a one-way fingerprint

Hashing condenses data into a fixed-size fingerprint that cannot be run backwards. SHA-256 turns any input — a byte or a terabyte — into 32 bytes, deterministically: the same input always gives the same hash, and any change to the input changes the hash completely.

The defining property: not reversible at all, by anyone, ever. This is not a limitation but the point. Hashes answer “is this the same data?” without revealing the data: file integrity checks (does the download match the published hash?), password storage (store the hash; check logins by hashing the attempt; a stolen database reveals no passwords), deduplication and change detection.

Two cautions from practice. MD5 and SHA-1 remain fine as checksums against accidental corruption but are broken against deliberate attack — collisions can be manufactured — so anything security-relevant should use SHA-256 or better; the hash generator produces all of them, labelled accordingly. And hashing unsalted passwords is barely better than plaintext, because common passwords have well-known hashes; real systems use salted, deliberately slow hashes (bcrypt, argon2).

The JWT case: where the confusion does damage

JSON Web Tokens are where these concepts collide most visibly. A JWT looks like line noise, but its first two sections are just Base64-encoded JSON — paste any JWT into the JWT decoder and the payload is instantly readable. No key involved.

The third section is a signature — hashing plus a key — which lets the server verify the token was not modified. So a JWT is tamper-evident but not confidential: anyone holding it can read the claims inside; they just cannot change them undetected. Sensitive data inside a JWT payload is a genuine and common security mistake, made by developers who saw gibberish and assumed encryption.

The one-table summary

	Reversible?	Needs a key?	Solves
Encoding (Base64)	Yes, by anyone	No	Transport
Encryption (AES)	Yes, with key	Yes	Secrecy
Hashing (SHA-256)	No	No	Integrity

When you meet an unreadable string, the question is never “how do I read this?” but “which of the three is it?” — the answer decides whether reading it is trivial, hard, or meaningless.