Hashing vs Encryption vs Encoding: What's the Difference

Encoding: making data safe to transport

Encoding transforms data into a different format so it can travel through a system that expects a particular shape. Base64, URL percent-encoding and HTML entities are all encodings. There is no key and no secret involved: anyone can reverse an encoding, and that is the whole point — the receiver needs to decode it.

Use encoding when the goal is compatibility, not secrecy: putting binary in a JSON field, carrying a value safely in a URL, or embedding an image as a data: URI. If you ever think of an encoding as 'protecting' data, that is the warning sign you have reached for the wrong tool.

Encryption: keeping data secret but recoverable

Encryption scrambles data with a key so that only someone with the right key can turn it back into the original. It is two-way by design — encrypt with the key, decrypt with the key (or its pair). The security rests entirely on keeping the key secret, not on hiding the algorithm.

Use encryption when you need to store or send something private that must later be read back: a message in transit (HTTPS), files at rest, or a database column holding sensitive personal data. The defining trait is recoverability: by design, the original can be retrieved — by whoever holds the key.

Hashing: a one-way fingerprint

Hashing runs data through a one-way function that produces a fixed-length digest. The same input always gives the same hash, but there is no key and no way back — you cannot derive the input from the output. A good cryptographic hash also makes it infeasible to find two inputs with the same digest.

Use hashing to verify rather than to recover: checking a download hasn't been tampered with, comparing two files, or de-duplicating content. Because it is irreversible, hashing is exactly what you want when you never need the original back — only to confirm whether something matches it.

The password example that ties it together

Passwords are where these three collide and where mistakes are most damaging. You should never encrypt a stored password, because encryption is reversible — anyone who steals the key gets every password. You hash it instead, so a breach reveals only digests, not the passwords themselves.

But a plain SHA-256 hash is too fast: an attacker can try billions of guesses per second. So password hashing uses a deliberately slow, salted algorithm such as bcrypt, scrypt or Argon2. The salt makes identical passwords hash differently, and the slowness makes mass guessing expensive. Encoding plays no part here at all.

A quick decision guide

When you are unsure which you need, ask what you are trying to achieve and pick accordingly.

• Need to send/store data and read the exact value back later, privately? Encryption.
• Need only to check whether data matches, never to recover it? Hashing — and for passwords, a slow salted hash (bcrypt/Argon2).
• Need to move data through a text-only or URL-only channel intact? Encoding (Base64, URL-encoding) — never for secrecy.
• Need to prove a message came from someone who holds a shared key? An HMAC, which combines a hash with a secret key.