Hashing, encryption and encoding sound similar and are constantly mixed up — including in production code, with real security consequences. They are not variations on a theme; they solve three completely different problems. Getting them straight prevents an entire category of bugs, from “secured” passwords that are not, to attempts to “decrypt” something that was never encrypted.
You can try the difference hands-on: the Hash Generator produces one-way fingerprints, and the Base64 tool encodes and decodes — both in your browser.
Encoding: format, not security
Encoding transforms data into a different format so it can travel safely — for instance, turning raw bytes into text-safe characters so they survive an email or a URL. The defining property: it is fully reversible by anyone, with no key and no secret. Base64, URL-encoding and HTML entities are all encoding.
Use it when data needs to change shape: binary in a JSON string, a value in a URL, the readable parts of a JWT (which are base64url-encoded, and therefore readable by anyone).
Encryption: confidentiality with a key
Encryption scrambles data so that only someone with the right key can turn it back into the original. Without the key it is unreadable noise; with the key, it reverses perfectly. The whole point is confidentiality — keeping data secret from anyone who lacks the key.
- Symmetric encryption uses the same key to encrypt and decrypt (e.g. AES) — fast, for data at rest and bulk transfer.
- Asymmetric encryption uses a public key to encrypt and a private key to decrypt (e.g. RSA) — the basis of HTTPS and digital signatures.
Use encryption when data must be secret but recoverable by an authorised party: messages, files, stored sensitive fields.
Hashing: one-way fingerprints
Hashing runs data through a function that produces a fixed-length fingerprint — and, crucially, cannot be reversed. There is no key and no “unhash.” The same input always gives the same hash; changing one bit changes the hash completely. Two uses dominate:
- Integrity — hash a file or message and compare later to detect any change (the basis of checksums).
- Passwords — store the hash, not the password. At login, hash what the user typed and compare. Because hashing is one-way, a leaked database does not directly reveal the passwords.
Side by side
| Encoding | Encryption | Hashing | |
|---|---|---|---|
| Purpose | Format / transport | Confidentiality | Integrity / fingerprint |
| Reversible? | Yes, by anyone | Yes, with the key | No, ever |
| Needs a key? | No | Yes | No |
| Provides security? | No | Yes (secrecy) | Yes (one-way) |
| Examples | Base64, URL-encode | AES, RSA | SHA-256, bcrypt |
The password rule
Passwords deserve special mention because they are where this gets dangerous. Passwords should be hashed, never encrypted or stored plainly — and not with a plain fast hash either. Use a slow, salted password-hashing function built for the purpose: bcrypt, scrypt or Argon2.
- Slow deliberately limits how many guesses an attacker can try per second.
- Salted (a unique random value per password) means identical passwords get different hashes, defeating precomputed “rainbow table” attacks.
A fast hash like SHA-256 alone is excellent for file integrity but a poor choice for passwords precisely because it is fast — an attacker can try billions of guesses per second.
In practice
Pick by the question you are answering: “will it survive transport?” → encoding; “must it stay secret but be readable later?” → encryption; “do I need a fingerprint or to store a password?” → hashing. Never substitute one for another — especially never mistake encoding for security. Experiment with the Hash Generator and Base64 tools, and see the whole picture in Developer Data Essentials.
Frequently asked questions
What is the difference between hashing, encryption and encoding?
Encoding changes data's format for transport and is reversible by anyone (no security). Encryption scrambles data so only someone with the key can read it (confidentiality, reversible with the key). Hashing produces a fixed-length fingerprint that cannot be reversed at all (used for passwords and integrity). They solve completely different problems.
Is base64 encryption?
No. Base64 is encoding — it rearranges bytes into a text-safe form that anyone can decode instantly. It provides zero security. Base64-ing a secret does not protect it; treating encoding as encryption is one of the most common security mistakes.
How should passwords be stored?
Hashed, never encrypted or plain. Use a slow, salted password hashing function designed for the job — bcrypt, scrypt or Argon2 — not a fast general hash like SHA-256 alone. Because hashing is one-way, even if the database leaks, the original passwords cannot be recovered directly.
Can you reverse a hash?
Not directly — hashing is designed to be irreversible. Attackers instead guess inputs and hash them to see if they match (a brute-force or dictionary attack), which is why slow hashing and per-password salts matter: they make guessing prohibitively expensive.
What is a salt, and why does it matter?
A salt is a unique random value added to each password before hashing. It means two users with the same password get different hashes, which defeats precomputed "rainbow table" attacks and stops an attacker from cracking many accounts at once. The salt is stored alongside the hash; it is not secret, just unique per password.
Is MD5 or SHA-1 safe to use?
Not for security. Both are broken — attackers can craft two different inputs with the same hash (a collision), so they must not be used to prove a file is authentic or to store passwords. They are still fine as quick, non-adversarial checksums to detect accidental corruption. Use SHA-256 or better when it actually matters.
When should I use encryption instead of hashing?
Use encryption when you need to get the original data back later — storing a secret you will read again, or sending a private message. Use hashing when you never need the original back, only to verify it: checking a password, or confirming a file has not changed. If the answer to "do I need to recover this?" is yes, you want encryption, not a hash.