All three turn one piece of data into another. That surface similarity is exactly why they get used interchangeably in casual conversation — and why mixing them up in actual code is a real, recurring security mistake, not just a vocabulary slip. Each one answers a completely different question, and confusing which one you need is how a password ends up "encrypted" in a way anyone can reverse, or "encoded" as if that hid anything at all.
The one-sentence version of each
| Reversible? | Needs a key? | What it's for | |
|---|---|---|---|
| Encoding | Yes, always | No | Making data compatible with a system that can't handle it as-is |
| Encryption | Yes, with the right key | Yes | Confidentiality — hiding data from anyone without the key |
| Hashing | No, never | No | Integrity and verification — proving data matches, without storing it |
Encoding: reversible, and anyone can reverse it
Encoding exists to solve a compatibility problem, not a secrecy problem: some systems — email, JSON, URLs, older text-only protocols — can't safely carry raw binary data, so encoding represents that data using a restricted set of characters instead. Base64 is the example everyone runs into constantly, and it makes the "no key" property concrete: decoding it back to the original is a lookup-table operation, the same in both directions, with nothing secret involved anywhere. Base64 Decode proves this in one click — there's no password to enter because none exists.
Encryption: reversible, but only with the right key
Encryption is the one of the three actually built for confidentiality — turning data into something unreadable to anyone who doesn't hold the specific secret required to turn it back. That secret is the whole mechanism: strip it away and encryption degrades into encoding, reversible by anyone, which is exactly why a cipher's security lives entirely in how well the key is generated and protected, not in the algorithm's name alone.
Real encryption splits into two families that solve different problems — symmetric (the same key encrypts and decrypts, fast, used for bulk data — AES is the standard example) and asymmetric (a public key encrypts, only the matching private key decrypts, slower, used to safely establish a shared secret in the first place — RSA and elliptic-curve algorithms are the standard examples). Every HTTPS connection uses both together: asymmetric encryption to agree on a session key without ever transmitting it, then fast symmetric encryption for the actual data. See AES vs RSA for exactly how that handshake works, and why RSA can't just replace AES (or the other way around) even though both are "encryption."
Hashing: not reversible, on purpose
Hashing throws information away deliberately. A hash function takes input of any size and produces a fixed-size output with no operation that turns that output back into the original — not a missing feature, the entire point. That makes it useless for anything you need to recover later, and exactly right for anything you only need to verify later: does this file match the one I downloaded, does this password match the one that was set. Password Hashing Explained covers why this property is specifically what password storage needs — a server that can verify a password without ever being able to recover it is a server that has nothing useful to hand over if its database leaks.
Why mixing these up is a real security mistake, not just imprecise language
- "Encoding" something as if it were protection. Base64 wrapped around a password or an API key in a config file looks obscured and provides exactly zero confidentiality — anyone who finds it decodes it instantly, no key required. If it needs to be hidden, it needs encryption, not encoding.
- Storing passwords "encrypted" instead of hashed. Encryption is reversible by design — whoever holds the key can recover every password at once, which means a stolen key (or a compromised server that has one) is as bad as a stolen plaintext database. Password Hashing Explained's common-mistakes section covers this exact failure mode directly: a one-way hash has no equivalent single point of failure, because there's no key anywhere that unlocks everything at once.
- Assuming HTTPS protects data once it's stored. TLS encrypts data in transit — the trip between a browser and your server. It has nothing to say about what happens to that data once it's written to a database, a log file, or a backup. Encryption at rest is a separate decision, made separately, and a system that only encrypts in transit is fully exposed the moment its storage is compromised directly.
FAQ
Can encoded data be "cracked"?
No, and the word doesn't really apply — cracking implies defeating a secret, and encoding has none. Decoding is the normal, intended, always-available operation, not an attack.
Why can't a hash just be decrypted back to the original password?
Because there's no decryption operation defined for a hash function at all — it's not encrypted data waiting for a key, it's a one-way computation that discarded the information needed to reverse it. The only way "in" is guessing candidate inputs and hashing each one to see if it matches, which is exactly what How Long Does It Take To Crack A Password? covers.
Is HTTPS enough to keep my users' data safe?
It's necessary, not sufficient — it protects data crossing the network, and does nothing for data sitting in your database, your backups, or your logs. Those need their own encryption-at-rest and access-control decisions, independent of whatever your connection uses.
Should passwords ever be encrypted instead of hashed?
No — a password only ever needs to be verified, never recovered, which is exactly what hashing is for. The one common exception in the other direction is something like a stored third-party API credential your own server needs to present again later — that genuinely needs to be recovered, so it's encrypted, not hashed. Different requirement, different tool.
Try it yourself
Base64 Encode and Base64 Decode make the "no key, fully reversible" property of encoding concrete, Password Hash Generator and Hash Comparison do the same for hashing's one-way property across real algorithms, and AES Encrypt/Decrypt does the same for encryption's "reversible, but only with the right key" property. All five run entirely in your browser.