Hashing, encryption, and encoding are three of the most confused concepts in software, and mixing them up leads to real security bugs — like Base64-encoding a password and thinking it is protected. This guide draws a clear line between the three: what each does, whether it can be reversed, and when to use it. Try hashing with the Hash Generator and encoding with the Base64 Encoder.
Three different jobs
The three are easy to separate once you ask two questions: is it reversible, and does it need a key?
| Technique | Reversible? | Needs a key? | Purpose |
|---|---|---|---|
| Encoding | Yes, by anyone | No | Represent data in another format |
| Encryption | Yes, with the key | Yes | Keep data confidential |
| Hashing | No | No | Verify integrity, store password verifiers |
Encoding
Encoding transforms data into another representation so it can travel safely, such as Base64 for binary data in text. It provides no security whatsoever — anyone can decode it without a key. If a value is Base64 or URL encoded, treat it as fully readable.
Encryption
Encryption scrambles data so that only someone with the correct key can read it. It is reversible by design, but only with the key. Use it when you need confidentiality — protecting data in transit or at rest. Modern symmetric encryption such as AES uses one shared key; asymmetric encryption uses a public key to encrypt and a private key to decrypt.
Hashing
Hashing turns any input into a fixed-length digest and is one-way: you cannot reverse a digest back to the input. The same input always yields the same digest, and a tiny change to the input produces a completely different one. That makes hashing ideal for verifying that data has not changed and for storing password verifiers without storing the passwords themselves.
Why passwords need special hashing
General-purpose hashes like SHA-256 are fast, which is exactly what you do not want for passwords — speed helps an attacker try billions of guesses. Passwords should use a slow, salted password hash such as bcrypt or Argon2. A salt, a unique random value added before hashing, ensures that two identical passwords produce different stored hashes and defeats precomputed lookup tables.
Choosing a hash algorithm
For integrity and fingerprints, use a modern secure hash; avoid the broken ones for anything security-related.
| Algorithm | Use |
|---|---|
| MD5 | Legacy checksums only — broken for security |
| SHA-1 | Deprecated for security |
| SHA-256 | Secure integrity checks and fingerprints |
| SHA-512 | Secure, larger digest |
| bcrypt / Argon2 | Password storage (slow and salted) |
Frequently asked questions
Is hashing reversible?+
No. Hashing is one-way — a digest cannot be turned back into the original input. You can only hash a candidate and compare digests.
Is Base64 encoding a form of encryption?+
No. Base64 is encoding: anyone can decode it without a key. It provides no confidentiality and must never be used to protect secrets.
Why can't I use SHA-256 for passwords?+
It is too fast, which helps attackers brute-force guesses. Passwords need a slow, salted hash like bcrypt or Argon2.
What is a salt?+
A unique random value added to a password before hashing, so identical passwords produce different stored hashes and precomputed attack tables do not work.