Hashing, encryption, and encoding get mixed up constantly, even by experienced developers. They all transform data into something unreadable, but they solve completely different problems and are not interchangeable. Confusing them causes real security bugs. Here is a clear, practical breakdown of what each one does, when to use it, and the mistakes to avoid.
The One-Sentence Difference
- Encoding changes the format of data so it can travel safely. It is reversible by anyone and provides zero security.
- Encryption protects data so only someone with the key can read it. It is reversible only with that key.
- Hashing produces a fixed-length fingerprint of data. It is a one-way function and cannot be reversed at all.
If you remember nothing else: encoding is for compatibility, encryption is for confidentiality, and hashing is for verification. Once you anchor on the purpose rather than the output, the differences stop being confusing.
Encoding: For Compatibility, Not Secrecy
Encoding converts data from one representation to another using a public, well-known scheme. Base64, URL encoding, ASCII, and UTF-8 are all encodings. The goal is to make data safe to store or transmit through a system that expects a particular format.
For example, Base64 turns binary data into printable text so it can survive an email server or sit inside a JSON field. URL encoding turns a space into %20 so it does not break a web address. None of this is secret. Anyone who sees the encoded string can decode it instantly, because the algorithm is public and requires no key.
The classic mistake is treating a Base64 string as if it hides something. It does not. A token, password, or API key that is only Base64-encoded is effectively in plain text. If you can decode it with a free online tool in two seconds, so can an attacker.
Encryption: For Confidentiality
Encryption scrambles data using an algorithm and a secret key, so that only someone holding the right key can turn it back into the original. Without the key, the output (called ciphertext) is meaningless. This is what actually protects data.
There are two broad families:
Symmetric encryption
The same key both encrypts and decrypts. AES is the dominant standard, used for everything from disk encryption to securing data at rest in databases. It is fast and well suited to large volumes of data. The challenge is key distribution: both parties need the same secret key, and getting it to them securely is its own problem.
Asymmetric encryption
This uses a key pair: a public key that anyone can use to encrypt, and a private key that only the recipient holds to decrypt. RSA and elliptic-curve cryptography work this way. It solves the key distribution problem, which is why it underpins HTTPS, signed software, and secure messaging. The trade-off is that it is slower, so in practice systems use asymmetric encryption to exchange a symmetric key, then switch to symmetric encryption for the bulk of the data.
The defining feature of encryption is that it is reversible by design. That is the whole point: the intended recipient must be able to recover the original message. If you never need to read the data back, you probably do not want encryption at all. You want hashing.
Hashing: For Verification
A hash function takes any input and produces a fixed-length string, the hash or digest. The same input always produces the same output, but you cannot run the process backward to recover the input. SHA-256, for example, turns any file, no matter how large, into a 64-character hexadecimal fingerprint.
Hashing has two main jobs:
Integrity checking
If you hash a file before and after a download and the two hashes match, the file was not altered or corrupted in transit. A single changed byte produces a completely different hash, which is exactly what you want for detecting tampering. This is why software downloads often publish a SHA-256 checksum next to the file.
Password storage
Systems should never store your actual password. Instead they store a hash of it. When you log in, the system hashes what you typed and compares it to the stored hash. If they match, you are in, and the real password was never kept anywhere. Even if the database leaks, attackers get hashes rather than passwords.
Why Passwords Need Special Hashing
This is the nuance that trips people up. General-purpose hashes like SHA-256 are designed to be fast, which is great for checking file integrity but terrible for passwords. An attacker with a leaked database can compute billions of SHA-256 hashes per second and match common passwords almost instantly.
Password hashing therefore uses deliberately slow, resource-intensive algorithms: bcrypt, scrypt, and Argon2. They add two defenses. A salt, a unique random value mixed into each password before hashing, ensures that two users with the same password get different hashes and defeats precomputed lookup tables. A configurable work factor makes each hash slow enough that mass guessing becomes impractical. Use these for passwords. Never use plain SHA-256 or MD5.
A Quick Decision Guide
- Need to send binary data through a text-only channel? Encode it (Base64).
- Need to read the data back later but keep it secret in the meantime? Encrypt it (AES or RSA).
- Need to verify data has not changed, or check a value without storing it? Hash it (SHA-256).
- Specifically storing passwords? Use a slow password hash (bcrypt, scrypt, or Argon2) with a unique salt.
The Mistakes That Cause Real Bugs
Three confusions show up again and again in code reviews and security audits:
- Treating encoding as security. Base64 hides nothing. If a secret is only encoded, it is exposed.
- Encrypting passwords instead of hashing them. If your system can decrypt a stored password back to plain text, so can anyone who steals the key. Passwords should be hashed, not encrypted.
- Using a fast hash for passwords. SHA-256 and MD5 are wrong for password storage. They are too fast and, in MD5's case, broken.
Try It Yourself
The fastest way to build intuition is to run data through each transformation and watch what comes out. Generate a SHA-256 or MD5 hash, encode and decode Base64, and compare the results side by side, all in your browser with nothing uploaded to a server.