Base64 is not encryption. It has never been. Sending a Base64-encoded password over HTTP is the same as sending it in plaintext — any attacker who intercepts it can decode it in under one second using a standard library. This mistake reaches production systems regularly.
The confusion is understandable: encoding, encryption, and hashing all transform data into something that looks like random characters. The outputs are visually indistinguishable to a non-specialist. But their security properties are completely different, and choosing the wrong one has real consequences. This guide covers all three precisely, with the same input processed through each.
Why These Concepts Get Confused
All three transformations produce output that looks like "garbled text." Given the strings below, can you immediately identify which is which?
- aGVsbG8=
- 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
- 6e61e9c7c80be2b3e52a7f58eb1d9ece
The first is Base64 encoding of "hello." The second is the SHA-256 hash of "hello." The third is a partial AES-128-ECB ciphertext. All three can be decoded, but only one requires a secret key to reverse.
The NIST Glossary defines these terms precisely. The OWASP Cryptographic Storage Cheat Sheet translates them into practical guidance for application developers.
Encoding
Definition: A reversible transformation using a public algorithm, requiring no key.
Purpose: Representing data in a different format for compatibility — not for security.
Examples: Base64 (binary data in email, JWTs), URL encoding (percent-encoding reserved characters), HTML entities (< for <), binary (8-bit byte representation), hexadecimal.
Reversibility: Fully reversible by anyone who knows the encoding scheme. No secret is involved.
When to use it: Use encoding when you need to transmit binary data through a system that expects text (Base64 in email), safely embed special characters in a URL (percent-encoding), or display user input without HTML injection risk (HTML entity encoding).
Use the Base64 Encoder/Decoder to convert between binary and Base64. Use the URL Encoder/Decoder for percent-encoding.
When not to use it: Do not use encoding to protect passwords, API keys, or any data that requires confidentiality. Base64-encoded data is plaintext data.
Encryption
Definition: A reversible transformation requiring a secret key. Without the key, the data is computationally unrecoverable.
Purpose: Confidentiality — ensuring only parties with the correct key can read the data.
Types:
Symmetric encryption uses the same key for encryption and decryption. AES (Advanced Encryption Standard) is the current standard — defined in NIST FIPS 197. AES-128 has a 128-bit key; AES-256 has a 256-bit key. The mode matters: AES-ECB is insecure for most uses; AES-GCM provides authenticated encryption and is the current recommendation for new systems.
Asymmetric encryption uses a public key to encrypt and a private key to decrypt. RSA is the standard asymmetric algorithm. TLS uses asymmetric encryption to establish a session key, then switches to symmetric encryption for the actual data transfer — because symmetric encryption is orders of magnitude faster.
Reversibility: Reversible, but only with the correct key. An attacker without the key cannot recover the plaintext.
When to use it: Use encryption when data must be stored or transmitted confidentially and retrieved later. Encrypted at-rest database columns, HTTPS transport, file encryption, encrypted messaging. The MDN SubtleCrypto API provides browser-native AES-GCM encryption.
Hashing
Definition: A one-way, deterministic transformation. The same input always produces the same output, but the output cannot be reversed to recover the input.
Purpose: Integrity verification and password storage (with correct configuration).
Properties:
Deterministic: SHA-256("hello") always produces the same 64-character hex string, on any machine, at any time.
One-way: Given a SHA-256 output, there is no algorithm to compute the original input. The only attack is brute force.
Collision resistant: It is computationally infeasible to find two different inputs that produce the same hash output. (SHA-256 has no known practical collision; MD5 and SHA-1 do — they are deprecated for security use.)
Avalanche effect: Changing one bit of input changes approximately half of the output bits unpredictably.
When to use it: Use hashing for file integrity verification (compare SHA-256 hashes to detect corruption or tampering), verifying download authenticity, Git commit IDs, and as a component of HMAC authentication.
Password hashing specifically: Plain SHA-256 is too fast for passwords — GPUs compute billions of SHA-256 hashes per second. Use bcrypt, scrypt, or Argon2. Our bcrypt Hash Checker explains the format. The HMAC Generator handles HMAC-SHA256 for API authentication.
Use the SHA-256 Hash Generator for integrity checks. The MD5 Hash Generator is available for legacy systems only — do not use MD5 for new security applications.
Side-by-Side Comparison
| Property | Encoding | Encryption | Hashing |
|---|---|---|---|
| Reversible | Yes | Yes (with key) | No |
| Requires a key | No | Yes | No |
| Deterministic | Yes | Depends on mode | Yes |
| Provides confidentiality | No | Yes | No |
| Detects tampering | No | With AEAD modes | Yes |
| Typical use | Format conversion | Data confidentiality | Integrity, passwords |
| Example | Base64, URL encoding | AES-GCM, RSA | SHA-256, bcrypt |
Decision guide: - Need to represent binary data as text? → Encoding (Base64) - Need to hide data from unauthorised parties? → Encryption (AES-GCM) - Need to verify data has not changed? → Hashing (SHA-256) - Need to store a password? → Slow hashing (bcrypt or Argon2, not SHA-256)
Common Mistakes in Production Systems
Mistake 1 — Storing passwords as SHA-256 or MD5 hashes without salt: Without a salt (a random value added to each password before hashing), two users with the same password produce the same hash. An attacker with a precomputed rainbow table cracks all matching passwords at once. bcrypt automatically generates and stores a random salt per password.
Mistake 2 — Using Base64 as security: APIs that Base64-encode an API key or password before sending it over HTTP have not added any security — they have added the appearance of security. Use HTTPS; the transport layer handles encryption.
Mistake 3 — Confusing HMAC with hashing: A plain hash of a message does not authenticate the sender — anyone can compute SHA-256("hello"). An HMAC (Hash-based Message Authentication Code) combines the message with a secret key before hashing, so only parties with the key can produce a valid HMAC. For API request signing, HMAC-SHA256 is standard.
Mistake 4 — Using MD5 or SHA-1 for new security features: Both are broken for collision resistance. SHA-256 or SHA-3 should be used in all new systems.