"Encode the password with Base64 to keep it safe." That sentence, said seriously in real meetings, betrays applied computing's most persistent confusion. Encryption, hashing and encoding are three radically different operations with incompatible purposes — and confusing them produces vulnerabilities, not just aesthetic errors.
The question that separates everything
To classify any data transformation, ask one question: is it meant to be reversed, and by whom?
- If it reverses with a secret (key) → it's encryption.
- If it must never reverse → it's hashing.
- If it reverses with no secret at all → it's encoding.
Neither Base64 nor hashing is encryption. Nor does encryption serve integrity verification the way a hash does. Each tool carries a different contract.
Encoding: translating representations
Encoding converts data between formats so it survives a specific channel. No key, no intent to hide anything: anyone can decode.
Base64 exists because many protocols (email originally, later data URIs and JWT) assume ASCII-safe text. Three arbitrary binary bytes become four characters from the alphabet A-Z a-z 0-9 + /. The price: +33% size.
btoa("Hola") // "SG9sYQ=="
atob("SG9sYQ==") // "Hola"
URL encoding (%20 for space), hex (48 65 6c...) or Base32 belong to this same family. None adds an atom of security: a Base64 password is a password readable with one command.
Hashing: the irreversible fingerprint
A cryptographic hash takes any input and produces fixed-length output with three contractual properties:
- Deterministic: the same input always yields the same hash.
- Avalanche effect: flipping one input bit changes roughly half of the output bits.
- Irreversible: no inverse operation exists; recovering the input would mean guessing values until collision.
const digest = await crypto.subtle.digest(
"SHA-256",
new TextEncoder().encode("password123")
);
// 0cf7... always 32 bytes long
Its natural territory is verification, not confidentiality:
- Checking download integrity against a published SHA-256.
- Storing credentials: you store the hash, never the password. At login you hash what was received and compare.
- Digital signatures and deduplication.
The critical nuance for passwords: general-purpose hashes like SHA-256 are fast by design, which is terrible against offline brute force. Password storage uses slow hashes with built-in salt — bcrypt, scrypt or Argon2 — where slowness IS the security feature.
Encryption: reversible confidentiality with a key
Encryption transforms data so only the key holder can read it. It is the only one of the three operations whose goal is secrecy.
Symmetric (AES-256-GCM): the same key encrypts and decrypts. Extremely fast, ideal for large volumes: encrypted disks, databases, established TLS channels. The key-distribution problem limits its direct use between strangers.
Asymmetric (RSA, ECC): public key encrypts, private key decrypts (or the reverse for signing). Solves initial exchange with no prior channel, at orders-of-magnitude slower speed.
In practice they combine: TLS uses asymmetric for seconds to agree on a session key, then symmetric for all subsequent traffic.
GCM deserves special mention: it is an AEAD mode adding authentication to encryption. An attacker flipping one ciphertext bit triggers an explicit decryption error instead of silently corrupt data. If your encryption mode doesn't authenticate (ECB, CBC without MAC), you have fragile confidentiality without integrity.
The definitive mental table
| Property | Encoding | Hash | Encryption |
|---|---|---|---|
| Reversible | Yes, no key | No | Yes, with key |
| Goal | Compatibility | Verification | Confidentiality |
| Key | No | No | Yes |
| Example | Base64, URL encode | SHA-256, Argon2 | AES-GCM, RSA |
Three real-world cases where the confusion costs dearly:
- "Encrypting" passwords with Base64 instead of hashing: any breach hands over credentials on a platter.
- Hashing documents to keep them secret: hash protects against modification, not reading.
- Using MD5 for verification in 2026: broken against deliberate collisions for years; for verifying downloads use SHA-256.
Try them all
If you want hands-on contact with every operation without installing anything: the Hash Generator computes SHA-256 and family over any text or file, the Multi-base Encoder compares Base64/Base32/Base58/Base85 over your data, and the Text Encryptor applies real AES-256-GCM in your browser.
FAQ
Can I decrypt a hash if I have enough computing power? Not "decrypt": invert via brute-force candidate testing. Against unsalted SHA-256 and weak passwords it's viable; against well-configured Argon2, it is not.
Why does the same text produce different hashes with salt? Because salt mixes into the input. Two users sharing a password produce different hashes, killing rainbow tables and hiding who shares credentials.
Is JWT encrypted or encoded? By default, encoded: its payload is Base64url readable by anyone. Only JWE (the rarer variant) encrypts. Signing a JWT (JWS) guarantees nobody modified it, not that nobody read it.
Compute instant SHA-256 hashes with the Hash Generator, free and right in your browser.