Encoding, Encryption, and Hashing: What Developers Need to Know

Encoding, encryption, and hashing are three distinct operations that developers frequently confuse. All three transform data, but they serve fundamentally different purposes and offer vastly different security properties. Misunderstanding the differences leads to real-world vulnerabilities — from "securing" API keys with Base64 to storing passwords with reversible encryption instead of hashing. This guide clarifies what each operation does, when to use it, and what happens when you choose the wrong one.

The Three Concepts Defined

Encoding: Changing Representation

Encoding transforms data from one format to another for compatibility or transport. The transformation is fully reversible and requires no secret key. The algorithm is public, and anyone who knows the encoding scheme can decode the data instantly. Encoding provides zero confidentiality — it is not a security tool.

Think of encoding like translating a message from English to Morse code. The "secret" to reading Morse code is knowing the Morse code table, which is public knowledge. Anyone with the table can decode the message. Encoding works the same way.

Encryption: Ensuring Confidentiality with a Key

Encryption transforms data so that only parties with the correct key can read it. The transformation is reversible, but only with the key. Without the key, the encrypted data (ciphertext) is computationally infeasible to recover. Encryption is the correct tool when you need to protect data from unauthorized access.

Think of encryption like putting a message in a locked safe. Anyone can see the safe exists, but only someone with the combination can open it and read the contents.

Hashing: One-Way Fingerprinting

Hashing transforms data into a fixed-size digest (fingerprint) that is not reversible. You cannot recover the original data from a hash. Hashing is deterministic — the same input always produces the same output — but even a tiny change in the input produces a completely different hash. Hashing is the correct tool for verifying integrity and storing passwords.

Think of hashing like a fingerprint. You can check whether two fingerprints match, but you cannot reconstruct a person from their fingerprint.

Encoding Examples

// Base64 — binary-to-text encoding
btoa("Hello World")           // "SGVsbG8gV29ybGQ="
atob("SGVsbG8gV29ybGQ=")     // "Hello World"

// URL encoding — makes strings safe for URLs
encodeURIComponent("a=1&b=2") // "a%3D1%26b%3D2"
decodeURIComponent("a%3D1%26b%3D2") // "a=1&b=2"

// UTF-8 — character encoding
// The emoji 😀 is stored as bytes F0 9F 98 80
// A UTF-8 decoder reads those bytes and displays 😀

Notice the pattern: every encoding operation has a trivial, public reverse operation. No secret is involved. Base64, URL encoding, UTF-8, hex encoding, and ASCII85 are all examples of encoding. They solve format compatibility problems, nothing more.

Encryption Examples

Symmetric Encryption (AES)

In symmetric encryption, the same key is used to both encrypt and decrypt. AES (Advanced Encryption Standard) is the most widely used symmetric cipher. AES-256-GCM is the current gold standard, providing both confidentiality and authenticity:

// Symmetric encryption: same key encrypts and decrypts
Plaintext: "Secret message"
Key:       a9f2c8e1...  (256-bit random key)
    ↓ AES-256-GCM encrypt
Ciphertext: 7b2f4a91c3e8...  (unreadable without the key)
    ↓ AES-256-GCM decrypt (with same key)
Plaintext: "Secret message"

// Without the key, decryption is computationally infeasible
// (~2^256 possible keys to brute force)

Asymmetric Encryption (RSA)

In asymmetric encryption, a public key encrypts and a separate private key decrypts (or vice versa for signatures). RSA, ECDSA, and Ed25519 are common asymmetric algorithms. This solves the key distribution problem — you can share your public key openly while keeping your private key secret:

// Asymmetric encryption: different keys for encrypt/decrypt
Plaintext: "Secret message"
    ↓ Encrypt with recipient's PUBLIC key
Ciphertext: 3f8a2b7c...
    ↓ Decrypt with recipient's PRIVATE key
Plaintext: "Secret message"

// Only the private key holder can decrypt
// The public key can be shared freely

TLS (HTTPS) uses a combination of both: asymmetric encryption to exchange a symmetric key, then symmetric encryption for the actual data transfer (because symmetric encryption is much faster).

Hashing Examples

// SHA-256 — cryptographic hash (used for integrity checks)
SHA-256("Hello World")  → "a591a6d40bf420...e8d4e0892d00"
SHA-256("Hello World!") → "7f83b1657ff1fc...7f3dea3edbd" // completely different!
SHA-256("Hello World")  → "a591a6d40bf420...e8d4e0892d00" // same input = same hash

// bcrypt — password hashing (slow by design, includes salt)
bcrypt("mypassword")    → "$2b$12$LJ3m4ys3Lf..." // includes cost factor and salt
bcrypt("mypassword")    → "$2b$12$Xk9a7fR2qP..." // different salt = different hash!

// argon2 — modern password hashing (memory-hard, resists GPU attacks)
argon2id("mypassword")  → "$argon2id$v=19$m=65536,t=3,p=4$..."

// You CANNOT reverse any of these to get the original input
// You can only check: does hash(candidate) == stored_hash?

For password storage, always use algorithms specifically designed for passwords: bcrypt, scrypt, or argon2. These are deliberately slow and memory-intensive to make brute-force attacks impractical. General-purpose hashes like SHA-256 are too fast — an attacker with a GPU can try billions of SHA-256 hashes per second.

Comparison Table

Property        | Encoding        | Encryption        | Hashing
----------------|-----------------|-------------------|------------------
Purpose         | Compatibility   | Confidentiality   | Integrity/verify
Reversible?     | Yes (no key)    | Yes (with key)    | No (one-way)
Key required?   | No              | Yes               | No
Security?       | None            | Strong            | Integrity only
Output size     | ~input size     | ~input size       | Fixed size
Examples        | Base64, URL,    | AES, RSA,         | SHA-256, bcrypt,
                | hex, UTF-8      | ChaCha20          | argon2, MD5*

* MD5 is cryptographically broken — do not use for security purposes.

Common Mistakes

Using Base64 for "Security"

This is the most common mistake. Developers sometimes Base64-encode sensitive data like API keys, passwords, or tokens, believing this provides some level of protection. It does not. Base64 is instantly reversible by anyone — it is an encoding, not encryption. Putting a Base64-encoded secret in client-side code, a URL parameter, or a public repository is exactly as insecure as putting the plaintext there.

// WRONG: This provides zero security
const apiKey = atob("c2VjcmV0LWFwaS1rZXktMTIz");
// Anyone can decode: atob("c2VjcmV0LWFwaS1rZXktMTIz") → "secret-api-key-123"

// RIGHT: Keep secrets server-side, use environment variables,
// or use a secrets manager. Never embed secrets in client code.

Storing Passwords with Encryption Instead of Hashing

Passwords should never be stored with reversible encryption. If an attacker breaches your database and obtains the encryption key (which must be stored somewhere accessible to your application), they can decrypt every password at once. With hashing, there is no key to steal — each password must be cracked individually, and a strong password hash like bcrypt or argon2 makes this prohibitively slow.

// WRONG: Encrypting passwords (reversible if key is compromised)
encrypted = AES.encrypt("user_password", server_key)
// If server_key leaks, ALL passwords are instantly exposed

// RIGHT: Hashing passwords (not reversible, each must be cracked individually)
hashed = bcrypt.hash("user_password", cost=12)
// Even if the hash leaks, recovering the password requires brute force
// At cost=12, bcrypt processes ~13 hashes/second — impractical for strong passwords

When to Use Each

  • Encoding — Use when you need to transport or store data in a different format: binary data in JSON (Base64), special characters in URLs (percent encoding), text in different character sets (UTF-8). Encoding solves format problems.
  • Encryption — Use when data must remain confidential: data at rest (encrypting database fields, disk encryption), data in transit (TLS/HTTPS), end-to-end encrypted messaging, encrypted backups, or encrypted configuration values. Encryption solves confidentiality problems.
  • Hashing — Use when you need to verify without revealing: password storage (bcrypt/argon2), data integrity verification (SHA-256 checksums for file downloads), digital signatures, commit hashes in Git, deduplication, and hash tables. Hashing solves integrity and verification problems.

Real-World Scenarios

Consider these practical situations and the correct approach for each:

  • Sending a user's avatar in a JSON API response — Encode it (Base64). You need to represent binary image data in a text format. No secret is involved.
  • Storing a user's credit card number — Encrypt it (AES-256-GCM). The card number must be retrievable for future charges but must not be readable if the database is compromised.
  • Storing a user's password — Hash it (bcrypt or argon2). You never need to retrieve the original password; you only need to verify that a login attempt matches the stored hash.
  • Verifying a downloaded file is not corrupted — Hash it (SHA-256). Compare the hash of your downloaded file against the published hash to confirm integrity.
  • Transmitting data between microservices over an internal network — Encrypt it (TLS/mTLS). Even internal networks should use encryption to prevent lateral movement after a breach.
  • Including a username and password in an HTTP header — Encode it (Base64 for Basic auth). But this only solves the transport format problem — you must also use HTTPS (encryption) to protect the credentials in transit.
  • Signing a JWT token — This uses hashing (HMAC-SHA256) or asymmetric signing (RS256/ES256). The payload is Base64-encoded (not encrypted), so anyone can read it. The signature only ensures integrity — the token has not been tampered with. If the payload contains sensitive data, the JWT should also be transmitted over HTTPS.

Related Guides

Try it now →