The Difference Between Encoding, Encryption, and Hashing

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 the request can decode it in under one second using a standard library call. This exact mistake ships to production regularly, usually hidden behind a variable name like encryptedToken or secretKey.

The confusion is understandable. Encoding, encryption, and hashing all transform data into something that looks like random characters. The outputs are visually indistinguishable to anyone who is not looking for the difference. Their security properties, however, are completely different, and picking the wrong one has real consequences. This guide defines all three precisely, runs the same input through each, and explains when to use which.

All three transformations produce output that looks like garbled text. Here are three strings, all derived from the same five-character input "hello":

`` aGVsbG8= (Base64) 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (SHA-256) U2FsdGVkX19+X1Z5b3VydGV4dGhlcmVmb3JlbG9vaw== (AES ciphertext) ``

They look similar. They are not. The first is Base64 encoding of "hello," reversible by anyone with a decoder. The second is the SHA-256 hash of "hello," irreversible by design. The third is AES ciphertext of "hello," reversible only by someone who holds the secret key. Only one of the three requires a key to undo.

That single distinction, whether a secret key is involved, is the cleanest way to separate the three concepts. The NIST Glossary defines these terms precisely. The OWASP Cryptographic Storage Cheat Sheet translates them into practical guidance for application developers. Read both before you write your next line of crypto code.

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, data URIs), URL encoding (percent-encoding reserved characters), HTML entities (< for <), hexadecimal, ASCII.

Reversibility: Fully reversible by anyone who knows the encoding scheme. No secret is involved, and the scheme is always public.

Base64 is specified in RFC 4648. It maps every three bytes of input to four characters from a 64-character alphabet, plus padding. The algorithm is fully documented. Anyone can implement it, and anyone can reverse it. That is the point: encoding is about format conversion, not confidentiality.

When to use it: Use encoding when you need to transmit binary data through a system that expects text (Base64 in email attachments, JWTs, data URIs), 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, session tokens, or any data that requires confidentiality. Base64-encoded data is plaintext data. Calling it "encrypted" in a variable name does not make it so.

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.

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 uses a 128-bit key; AES-256 uses a 256-bit key. The block mode matters more than people assume. AES-ECB is insecure for almost every real use because identical plaintext blocks produce identical ciphertext blocks, leaking structure. AES-GCM provides authenticated encryption: it guarantees both confidentiality and integrity in a single operation, and it is the current recommendation for new systems. Use AES-GCM unless you have a specific reason not to.

Asymmetric encryption uses a public key to encrypt and a private key to decrypt. RSA is the standard asymmetric algorithm. You share the public key freely; only the holder of the private key can decrypt. Asymmetric encryption is slower than symmetric encryption by several orders of magnitude, so it is rarely used to encrypt bulk data directly.

TLS combines both. During the TLS handshake, the client and server use asymmetric encryption (or key agreement, such as ECDHE) to establish a shared session key. Once both sides hold that key, they switch to symmetric encryption (typically AES-GCM) for the actual data transfer. This is how HTTPS works: asymmetric crypto solves the key-distribution problem, symmetric crypto handles the fast bulk transfer.

Reversibility: Reversible, but only with the correct key. An attacker without the key cannot recover the plaintext in any practical timeframe.

When to use it: Use encryption when data must be stored or transmitted confidentially and retrieved later. Encrypted database columns, HTTPS transport, file encryption, encrypted messaging, encrypted backups. The MDN SubtleCrypto API provides browser-native AES-GCM encryption for client-side applications.

Definition: A one-way, deterministic transformation. The same input always produces the same fixed-length output, but the output cannot be reversed to recover the input.

Purpose: Integrity verification, fingerprinting, and password storage (with the right algorithm).

Properties:

Deterministic: SHA-256("hello") always produces the same 64-character hex string, on any machine, at any time, in any language. This is why hashes work for integrity checks.

One-way: Given a SHA-256 output, there is no algorithm that recovers the original input in less time than brute force. You can hash forward; you cannot compute backward.

Collision resistant: It is computationally infeasible to find two different inputs that produce the same hash output. SHA-256 has no known practical collision as of 2026, running all 64 rounds. MD5 and SHA-1 do not share this property, which is why they are deprecated for security use.

Avalanche effect: Changing one bit of input changes approximately half of the output bits unpredictably. The hash of "hello" and the hash of "Hello" share no visible pattern.

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, content addressing, and as a component of HMAC authentication.

Password hashing specifically: Plain SHA-256 is too fast for passwords. Modern GPUs compute billions of SHA-256 hashes per second, which makes brute-force attacks against stolen password databases trivially cheap. For passwords, OWASP recommends Argon2id first, then bcrypt or scrypt. These algorithms are deliberately slow and memory-hard, which raises the cost of an offline attack by orders of magnitude. They also handle salt internally, so you do not have to manage it yourself.

Use the SHA-256 Hash Generator for integrity checks. The bcrypt Hash Checker lets you verify a bcrypt hash against a plaintext input. The HMAC Generator handles HMAC-SHA256 for API request signing. The MD5 Hash Generator exists for legacy systems only; do not use MD5 for new security work.

Decision guide:

- Need to represent binary data as text? Use encoding (Base64). - Need to hide data from unauthorized parties? Use encryption (AES-GCM). - Need to verify data has not changed? Use hashing (SHA-256). - Need to store a password? Use slow hashing (Argon2id, or bcrypt), not SHA-256.

Mistake 1: Storing passwords as SHA-256 or MD5 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 and Argon2 generate and store a random salt per password automatically. If you are rolling your own salt logic, you are probably doing it wrong.

Mistake 2: Using Base64 as security. APIs that Base64-encode an API key or password before sending it over HTTP have added zero security. They have added the appearance of security, which is worse, because it discourages the real fix. Use HTTPS. The transport layer handles encryption; you do not need to layer a broken scheme on top.

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 holding the key can produce a valid tag. For API request signing, HMAC-SHA256 is the standard pattern.

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. There is no good reason to reach for MD5 or SHA-1 in 2026.

This guide covers the core distinctions, but real systems have edge cases worth naming.

Encryption alone does not guarantee integrity. AES-CBC without a MAC is malleable: an attacker can modify the ciphertext and the decryption will produce valid-looking but wrong plaintext. Use an authenticated mode like AES-GCM, or combine encryption with a separate HMAC, to get both properties.

Hashing is not authentication. A hash proves a file has not changed; it does not prove who sent it. For that, you need a signature (asymmetric) or an HMAC (symmetric). Conflating the two is a common source of bugs in API design.

Password hashing recommendations shift over time. Argon2id is the current OWASP preference, but bcrypt remains a sound choice with correct cost parameters. scrypt is also acceptable. The wrong choice is any plain, fast hash function, regardless of how long its output looks.

Finally, none of these concepts replace key management. AES-GCM is useless if the key is hardcoded in source, committed to a public repository, or logged to plaintext. The algorithm is rarely the weakest link; the key handling usually is.

Stop guessing which transformation you need. Run the same input through all three right now: paste "hello" into the Base64 Encoder/Decoder, the SHA-256 Hash Generator, and the bcrypt Hash Checker, and compare the outputs side by side. Seeing the difference in your own browser is worth more than reading another paragraph about it.