Encoding vs encryption vs hashing: what is the difference
Tools Nimbus is a free, no-signup developer toolkit that runs entirely in your browser, so your data is never uploaded to a server. Encoding, encryption, and hashing solve three problems: encoding rewrites data for safe transport and is reversible with no key, encryption hides data and is reversible only with a key, and hashing is a one-way digest you cannot reverse. Try encoding with the Base64 Encoder and Decoder and hashing with the Hash Generator.
Last updated June 2026
Three words people use interchangeably, and shouldn't
Encoding, encryption, and hashing all transform data into something that looks scrambled, so they get mixed up constantly, including in bug reports and security reviews. The distinction is not academic: confusing them causes real failures, from passwords stored in a form anyone can read to data that was supposed to be secret shipped in plain Base64. The clean way to tell them apart is to ask two questions. Can it be reversed? And does reversing it require a secret key? Those two answers separate the three cleanly.
Side by side
| Property | Encoding | Encryption | Hashing |
|---|---|---|---|
| Purpose | Safe representation and transport | Confidentiality (secrecy) | Integrity and verification |
| Reversible? | Yes, by anyone | Yes, with the key | No, one-way |
| Uses a key? | No | Yes | No (a salt is not a secret key) |
| Output size | Grows with input | Roughly input size | Fixed, regardless of input |
| Provides secrecy? | No | Yes | No (but hides the original) |
| Common examples | Base64, URL percent-encoding, HTML entities | AES, RSA, TLS | SHA-256, SHA-512, bcrypt, Argon2 |
| Typical use | Email attachments, data URIs, query strings | Stored secrets, messages in transit | Checksums, fingerprints, password storage |
Encoding: a format change, not a lock
Encoding rewrites bytes into a different representation so they survive a channel that would otherwise mangle them. Base64 turns binary into 64 printable characters so it can ride inside text-only formats like email and JSON. URL percent-encoding escapes characters that have special meaning in a URL. HTML entities let you put a literal <in a page without starting a tag. None of these use a key, and every one is reversible by anyone who recognizes the scheme. That is the whole point: the receiver must be able to decode it. So encoding gives you portability, never secrecy. You can confirm this in seconds by pasting any "scrambled" Base64 into the Base64 Encoder and Decoder or a percent-encoded value into the URL Encoder and Decoder and watching the original text reappear instantly with no password asked.
Encryption: reversible, but only with the key
Encryption is the only one of the three designed to keep data secret. It runs plaintext through a cipher such as AES along with a key, producing ciphertext that is computationally infeasible to reverse without that key. Give the key to an authorized party and they recover the exact original; without it, the ciphertext is useless. The key is the entire security boundary, which is why key management, not the algorithm, is where most real systems succeed or fail. Encryption is the right tool whenever someone must later read the original value back: a secret in a database, a file at rest, a session between a browser and a server. It is also why proper encryption needs a vetted library and secure key storage, not a browser text box, so Tools Nimbus deliberately does not offer an "encrypt" toy that would give a false sense of safety.
Hashing: one-way by design
Hashing feeds data into a function like SHA-256 that produces a fixed-size digest, 64 hex characters for SHA-256 no matter whether the input is one byte or a gigabyte. The defining property is that it cannot be reversed: there is no key and no inverse function, so you cannot compute the input from the digest. The same input always yields the same digest, and any change to the input, even one bit, produces a completely different one. That makes hashing ideal for integrity (does this file match the published checksum?), fingerprinting (have I seen this exact blob before?), and password storage (store the hash, compare hashes at login, never keep the plaintext). You can see the fixed-length, avalanche behavior directly in the Hash Generator, which computes SHA-1, SHA-256, SHA-384, and SHA-512 locally through the Web Crypto API.
Hashing passwords is not just hashing
One nuance trips up almost everyone: a plain SHA-256 of a password is not safe storage. Fast hashes are easy to brute-force at billions of guesses per second, and identical passwords produce identical digests. Real password storage adds a unique random salt per user and uses a deliberately slow algorithm such as bcrypt, scrypt, or Argon2 so each guess costs real time. The salt is not a secret key, it just stops precomputed rainbow tables; the one-way property still comes from the hash. If you only need a strong value to begin with, the Password Generator creates high-entropy passwords in your browser.
How to pick in one sentence
Choose encoding when you only need data to travel safely and anyone may reverse it; choose encryption when an authorized party must read the original back later and no one else may; choose hashing when you never need the original again and only need to verify or compare. When you catch yourself reaching for Base64 to "hide" something, that is the signal you actually wanted encryption or hashing. For more on the encoding side, see Base64 vs Base64URL, and for hashing in practice see the best free offline password generator. The full library of tutorials lives on the Tools Nimbus guides index.