Protect & Encrypt · Field note
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.
Before you start
Run the workflow once with a disposable value, then do a decrypt or restore check before you share anything real.
In brief
What it is: 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.
Watch for: 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.
- If you inherited an unfamiliar value, identify its structure before choosing a decoder or verifier. A bare digest-shaped value can fit several algorithms, while marked password hashes carry stronger format evidence.
| 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.
- Naming a bare 32-, 40-, or 64-character digest from length alone even though several algorithms and arbitrary bytes can share that shape.
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
- Only the encryption example needs a secret to reverse the operation later.
- The hash output cannot be used to recover the original input.