Hashing vs Encryption vs Encoding: What Every Developer Should Know

Few topics in software produce more confusion than the difference between hashing, encryption, and encoding. They're all transformations on data. They all involve weird-looking output. They all show up in security contexts. And they're all wildly different in purpose. Conflating them produces some of the worst security bugs in production — passwords stored with Base64 "encryption," tokens "hashed" with reversible algorithms, encrypted data with no integrity protection.

This article lays out exactly what each one is for, when to use it, and the common mistakes that come from mixing them up. It's the conversation every developer should have early in their career — and the one many never have at all.

Encoding: making data fit a channel

Encoding transforms data from one representation to another for transport or storage compatibility. There is no secret, no key, no security goal. Anyone can decode encoded data without any special knowledge. Base64, URL encoding, HTML entity escaping, UTF-8, hexadecimal — these are all encodings.

The purpose is purely practical: get binary data through a text channel (Base64), make a string safe inside a URL (URL encoding), prevent characters from being interpreted as HTML markup (HTML entity escaping), and so on. Encoding is reversible by design.

Mistake to avoid: "the API key is base64-encoded in the config so it's safe." Decoding Base64 takes one line in any language. Encoded ≠ secure.

Hashing: one-way fingerprints

A hash function takes input of any size and produces a fixed-size output. The output looks random, and tiny changes to the input cause completely different output. Critically, hashes are one-way — you cannot recover the original input from the hash, even in principle. Two different inputs that produce the same hash form a "collision," and good hash functions make collisions vanishingly unlikely.

Hashes are used for integrity verification (download a file, compare its hash to the published value), identifying duplicate content (Git uses SHA-1 to identify file contents), and password storage (more on this below). General-purpose hash functions include SHA-256, SHA-3, and BLAKE3. Specialized password hashes include bcrypt, scrypt, and Argon2.

Mistake to avoid: hashing passwords with SHA-256 directly. SHA-256 is too fast — modern GPUs compute billions of SHA-256 hashes per second, which makes brute-forcing common passwords trivial. Use bcrypt, scrypt, or Argon2id specifically because they're slow.

Encryption: confidentiality with a key

Encryption transforms plaintext into ciphertext using a key, and the operation is reversible — decryption with the same key (symmetric) or the matching key (asymmetric) recovers the original plaintext. Without the key, ciphertext is computationally infeasible to reverse.

Symmetric encryption (AES-256-GCM, ChaCha20-Poly1305) uses the same key to encrypt and decrypt. It's fast and good for bulk data — encrypting files, database fields, network traffic. Asymmetric encryption (RSA, elliptic curve cryptography) uses a public key to encrypt and a private key to decrypt. It's slower but enables scenarios like "anyone can send me a message I alone can read."

Mistake to avoid: using AES-CBC or AES-ECB without authentication. Modern usage should be AES-GCM or ChaCha20-Poly1305, which combine encryption with a built-in MAC so any tampering is detected.

A practical comparison table

• Encoding — Purpose: transport compatibility. Reversible: yes, trivially, no key needed. Examples: Base64, URL encoding, hex.
• Hashing — Purpose: integrity, fingerprints, password storage. Reversible: no. Examples: SHA-256, bcrypt, Argon2.
• Encryption — Purpose: confidentiality. Reversible: yes, with the correct key. Examples: AES-256-GCM, ChaCha20-Poly1305, RSA.
• MAC (HMAC) — Purpose: integrity + authenticity. Reversible: no. Examples: HMAC-SHA256.
• Signature — Purpose: integrity + non-repudiation. Reversible: no. Examples: RSA-PSS, ECDSA, Ed25519.

Storing passwords correctly

Storing passwords in plaintext is malpractice. Hashing them with MD5, SHA-1, or SHA-256 is barely better — the algorithms are fast enough that rainbow tables crack the most common passwords instantly.

The correct approach in 2026: hash with Argon2id (preferred) or bcrypt (well-established). Both algorithms are deliberately slow and use unique salts per password, so even identical passwords across different users produce different hashes, and brute force takes years per password instead of seconds.

Even better: don't store passwords at all. Use passkeys (WebAuthn) where you can. They eliminate the entire password breach risk.

When to use what — a decision tree

Need to put binary data in a URL or JSON field? Encoding (Base64URL).

Need to verify a file wasn't corrupted in transit? Hashing (SHA-256).

Need to store passwords? Specialized password hashing (Argon2id or bcrypt).

Need to keep data secret in transit or at rest? Symmetric encryption (AES-256-GCM).

Need to prove a message came from a specific party and wasn't modified? MAC (HMAC) for shared-key scenarios, signature (Ed25519) for public-key scenarios.

Need anyone to be able to encrypt something only you can read? Asymmetric encryption (RSA-OAEP or hybrid like ECDH + symmetric).

Use libraries, never roll your own crypto

Cryptography is full of subtle ways to get it wrong. Padding oracle attacks, timing attacks, weak random number generators, key reuse — any one of them can break a system that looks correct on paper. The right answer is almost always to use a well-audited high-level library: libsodium, the Web Crypto API, your platform's built-in crypto module. Never invent your own protocol or algorithm.

If you find yourself reaching for `Buffer.xor()` or implementing AES from scratch, stop and find the library.

Wrapping up

Encoding is for making data fit a channel. Hashing is for one-way fingerprints. Encryption is for keeping data secret. MACs and signatures are for proving who sent what. They're not interchangeable, and using one where another belongs creates real security problems.

If you need to generate a hash for a file or string right now, our free hash generator supports MD5, SHA-1, SHA-256, SHA-384, and SHA-512, runs entirely in your browser, and never uploads what you paste in.