Hashing vs Encryption vs Encoding: The Difference

These three words get swapped around constantly, often in the same sentence, and the confusion is not harmless. Treating encoding as if it were encryption is one of the most common ways sensitive data ends up exposed. Each technique transforms data, but they answer completely different questions. Here is the distinction in plain terms, with the cases where each one is the right choice.

The one-line summary

• Encoding answers “can this data travel safely?” It is reversible by anyone, no key.
• Encryption answers “can only the right person read this?” It is reversible only with a secret key.
• Hashing answers “is this the same data as before?” It is one-way, not reversible at all.

Encoding: making data portable

Encoding changes the representation of data so it survives a particular channel. It has no secret and no key, which means it offers no privacy whatsoever. Base64 is the classic example: it turns binary into text so it can sit inside a URL, an email or a JSON string. URL-encoding (turning a space into %20) is another. Anyone can reverse encoding instantly, so its only job is compatibility, never secrecy.

Encryption: making data private

Encryption scrambles data using a key, so that only someone holding the right key can turn it back into the original. Without the key, the output is meaningless. This is the only one of the three that actually provides confidentiality. It comes in two broad flavours: symmetric, where the same key both locks and opens it (fast, used for bulk data), and asymmetric, where a public key locks and a private key opens it (used for key exchange and signatures).

The catch with encryption is key management. The secrecy lives entirely in the key, so a strong, well-protected key is the whole game. If you need a high-entropy value to use as one, a secret key generator produces something far harder to guess than anything you would type by hand.

Hashing: proving data is unchanged

A hash takes any input and produces a fixed-length fingerprint. The same input always yields the same fingerprint, and changing a single byte changes the result completely. Crucially, it is one-way: you cannot work backwards from the fingerprint to the data. That is the point. Hashing is how a download page proves a file was not tampered with, and how a login system can check a password without ever storing the password itself.

Not all hashes are equal. MD5 is fast but broken for security; SHA-256 is the modern default for integrity checks. For the full comparison, see our guide on MD5 vs SHA-256.

Putting them together: how a JWT works

A JSON Web Token is a great example because it uses two of the three at once, and tricks people into thinking it uses the third. A standard JWT is encoded with URL-safe Base64 (so it fits in an HTTP header) and signed with a hash-based signature (so tampering is detectable). It is usually not encrypted, which means anyone can read its payload. Paste one into a JWT decoder and you will see the claims in plain text. The signature guarantees integrity, not secrecy, so never put anything private inside a normal JWT.

A quick decision guide

Frequently asked questions

Is encoding the same as encryption?

No. Encoding is reversible by anyone and uses no key, so it gives no privacy. Encryption needs a secret key to reverse, which is what makes it private. Base64 is encoding, not encryption.

Can you reverse a hash?

Not directly. A hash is one-way by design. Tools that claim to decrypt a hash are really looking the value up in a table of known inputs, which only works for common or weak values.

Which one should I use to store passwords?

Hashing, but a slow password-specific hash such as bcrypt, scrypt or Argon2 with a salt. Never store passwords with encoding, and avoid plain fast hashes like MD5 or raw SHA-256.

Is a JWT encrypted?

Usually not. A standard JWT is Base64url-encoded and signed, so anyone can read its contents. The signature proves it was not altered, but it does not hide the data inside.