Encryption vs Encoding vs Hashing: What Each One Does
A clear decision guide to choosing encryption, encoding, or hashing so you use the right tool for the job.
Tip
Run the workflow once with a disposable value, then do a decrypt or restore check before you share anything real.
Summary
Definition: Encryption, encoding, and hashing solve different problems even when users casually describe them with the same word.
Why it matters: Picking the right primitive prevents broken workflows and false security assumptions in any tool-heavy workflow.
Pitfall: Using a reversible encoding where secrecy is needed or using a one-way hash where recovery is required later.
People often say “encrypt,” “encode,” and “hash” as if they are interchangeable. They are not. In practice those terms map to very different tool families, and choosing the wrong one creates either broken workflows or a false sense of security.
Use this rule: encrypt when someone needs to recover the original secret, encode when data needs to travel through text-only systems, and hash when you only need a one-way fingerprint or password verifier.
What actually separates them
- Choose encryption when the receiver must get the original message, file, link, or PDF back.
- Choose encoding when the content is not secret but the system receiving it needs a text-safe format.
- Choose hashing when you want comparison, integrity checking, or password verification without revealing the original value.
- If the word “decrypt” needs to happen later, you are in encryption territory, not hashing.
| Method | Main goal | Reversible | Needs a secret | Typical tools |
|---|---|---|---|---|
| Encryption | Hide the original content from anyone without the key or passphrase | Yes | Yes | Protect Text, Encrypt Text, Encrypt File, Encrypt Link, Encrypt PDF |
| Encoding | Represent data in a safer transport format | Yes | No | Base64 Encode, URL Encode, JSON to Base64, XML to Base64 |
| Hashing | Create a one-way fingerprint or password verifier | No | No | SHA-256 Generator, MD5 Generator, Bcrypt Generator |
Mistakes that lead to the wrong choice
- Treating Base64 as security. It is transport-friendly text, not secrecy.
- Storing passwords with reversible encryption instead of a dedicated password hash.
- Using a general hash where a password hash like bcrypt is the safer fit.
- Hashing something and later expecting to decrypt it.
Questions that settle the choice
Can I hash something and decrypt it later?
No. Hashes are one-way by design. If you need the original content back, use encryption instead.
Is Base64 good enough for secrets?
No. Base64 only changes representation. Anyone can decode it back to the original value.
Should passwords be encrypted or hashed?
Passwords should normally be stored with a password-hashing algorithm such as bcrypt, not reversible encryption.
Do this locally (CLI)
Use these side-by-side commands when you need to explain the primitive choice without any extra theory.
# Encoding
printf '%s' 'hello' | openssl base64 -A
# Encryption
printf '%s' 'hello' | openssl enc -aes-256-cbc -a -salt -pbkdf2 -pass pass:'"$PASSPHRASE"
# Hashing
printf '%s' 'hello' | sha256sum
What to notice:
- Only the encryption example needs a secret to reverse the operation later.
- The hash output cannot be used to recover the original input.
Developer workflow
Use this guide as a local handling check before a secret or protected file leaves your machine.
- Start with a harmless value that has the same shape as the real secret.
- Run the matching browser tool and copy the result into a scratch note.
- Run the decrypt, restore, or verification step before you share the real output.
1. disposable input
2. browser-only protect/encrypt step
3. decrypt or restore check
4. share only the intended artifact