Encryption vs Encoding vs Hashing: The Complete Guide

Three words get used interchangeably in bug reports, code reviews, and security audits, and mixing them up has caused more real breaches than any exotic cryptographic weakness. Encryption, encoding, and hashing all take data in and produce unreadable-looking data out. That surface similarity is exactly the trap. They exist for three completely different reasons, and the difference is not about strength — it is about reversibility and who holds a secret.

Here is the distinction in a single sentence each. Encoding is reversible by anyone, with no secret involved. Encryption is reversible only by someone holding the key. Hashing is not meant to be reversible at all. Everything else in this guide follows from those three facts.

The One Table That Settles It

	Encoding	Encryption	Hashing
Purpose	Data format compatibility	Confidentiality	Integrity and verification
Reversible?	Yes, by anyone	Yes, with the key	No, by design
Requires a secret?	No	Yes — a key	No
Output length	Proportional to input	Roughly proportional to input	Fixed, regardless of input
Typical examples	Base64, hex, URL encoding, Base32	AES-256-GCM, ChaCha20-Poly1305, RSA	SHA-256, SHA-3, Argon2
Fails when	The receiving system uses a different scheme	The key leaks	The algorithm loses collision resistance
Never use it for	Hiding anything	Storing user passwords	Data you need to read back

If you take nothing else away: the row that matters most is "requires a secret." Encoding has no secret, so it offers no protection. Hashing has no secret either, but it also never gives the data back, which is what makes it useful for verification. Only encryption has both a secret and a way back.

Encoding: Making Bytes Survive the Journey

Encoding solves a plumbing problem. Computers store everything as bytes, and a byte can hold any of 256 values. But plenty of systems that move data around cannot handle all 256 — email transport was historically 7-bit ASCII only, URLs reserve characters like ?, &, and # for structure, and JSON strings cannot contain raw control bytes. Encoding converts arbitrary bytes into a restricted, safe alphabet so they arrive intact.

Base64 takes three bytes (24 bits) at a time and re-splits them into four 6-bit groups, mapping each group to one of 64 characters: A-Z, a-z, 0-9, +, and /, with = used as padding. Because four output characters represent three input bytes, Base64 output is about 33% larger than the input. That size penalty is the price of compatibility.

Input:   Hello
Base64:  SGVsbG8=
Hex:     48656c6c6f

Both of those outputs represent exactly the same five bytes. Neither one is protected in any sense. Paste SGVsbG8= into the Base64 Encoder / Decoder and Hello comes straight back, no key, no configuration, no permission required. The same applies to the Hexadecimal Byte Encode / Decode tool, where each byte becomes two hex characters — larger output than Base64, but far easier to read a byte at a time, which is why hex dominates in debugging, checksums, and protocol documentation.

URL encoding (percent-encoding) follows the same principle with a different alphabet: unsafe characters become % followed by two hex digits, so a space becomes %20 and & becomes %26. Base32 uses only A-Z and 2-7, sacrificing density for case-insensitivity and human typeability. Base58 drops visually ambiguous characters so a hand-copied string is harder to get wrong. Each is a different trade between output size, character set, and human handling — a topic worth its own comparison, which we cover in Base32, Base58 and Base64url: Which Encoding When?.

The Mistake Everyone Makes

Base64 output looks scrambled, and that appearance has convinced generations of developers that it hides something. It does not. There is no scenario in which Base64, hex, ROT13, or URL encoding provides confidentiality. If you find an API key, a password, or a session token stored as Base64 in a config file or sent as a Base64 request parameter, treat it as fully exposed plaintext, because that is what it is.

The legitimate pattern is the reverse order: encrypt first, then encode the ciphertext so it can travel as text. Encoding is the envelope; encryption is the lock. An envelope with no lock is just an envelope.

Encryption: Confidentiality With a Key

Encryption transforms plaintext into ciphertext using a key, such that the transformation can only be undone by someone who has the corresponding key. Take the key away and the ciphertext is computationally useless — not merely inconvenient to read, but infeasible to read within any practical amount of time.

The security of a modern cipher rests entirely on the key, never on the algorithm being secret. This is Kerckhoffs's principle, and it is why AES, RSA, and ChaCha20 are all published in full public detail. An algorithm that depends on its own obscurity has never survived contact with real scrutiny. When you evaluate any system that claims to encrypt your data, the only question that matters is: who can obtain the key?

Symmetric Encryption

In symmetric encryption, the same key encrypts and decrypts. It is fast — modern CPUs have dedicated AES instructions that encrypt gigabytes per second — which makes it the right tool for bulk data: files, database columns, disk volumes, and the body of every HTTPS connection you make.

AES is the dominant symmetric cipher. It is a block cipher operating on 128-bit blocks, with key sizes of 128, 192, or 256 bits. The mode of operation matters as much as the key size: AES-256-GCM is the modern default because it is authenticated encryption, producing both ciphertext and an authentication tag that detects any tampering. Older modes like CBC provide confidentiality only and need a separate MAC bolted on correctly to be safe — a step that is easy to get wrong. You can try encryption and decryption directly in the browser with the AES Encryption & Decryption tool, and the mechanics are unpacked step by step in How AES Encryption Works (Without the Math).

Symmetric encryption has one hard problem: both parties need the same key, and getting it to them securely is a genuine challenge. Which is where the other family comes in.

Asymmetric Encryption

Asymmetric — or public-key — encryption uses a mathematically linked pair of keys. Anyone can encrypt with the public key, but only the holder of the private key can decrypt. Run in the other direction, the private key signs and the public key verifies, which is what gives you digital signatures and certificate chains.

RSA, the best-known example, derives its security from the difficulty of factoring the product of two large prime numbers. It is orders of magnitude slower than AES and can only encrypt payloads smaller than its key size, so it is almost never used for bulk data. Instead it does two jobs superbly: exchanging or wrapping a symmetric key, and signing.

That combination is exactly how HTTPS works in practice. Asymmetric cryptography authenticates the server and establishes a shared secret; a symmetric cipher then encrypts the actual traffic. Neither family replaces the other — they are used together, and the division of labour is covered in Symmetric vs Asymmetric Encryption Explained, with the key-generation details in RSA Key Pairs: What They Are and How to Generate Them.

Hashing: A Fingerprint, Not a Lock

Hashing takes input of any size and produces a fixed-length digest — 256 bits for SHA-256, always, whether the input is a single character or a 4 GB video file. The function is deterministic, so the same input always yields the same digest, and one-way, so the digest cannot be turned back into the input. There is no key, and there is no decrypt operation, because there is nothing to decrypt: hashing deliberately destroys information.

That destruction is the feature. It means you can prove two things match without storing or transmitting either one. Compare the digest of a downloaded file against the publisher's digest and you learn whether a single byte changed. Compare the hash of an entered password against a stored hash and you verify the password without ever keeping the password itself.

SHA-256("Hello") = 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

You can reproduce that with the SHA-256 Hash Generator — the value is identical everywhere, forever, in every language and on every machine. Hashing is a large topic in its own right, covering the avalanche effect, collision resistance, and the state of MD5, SHA-1, and SHA-2; for the full treatment see The Complete Guide to Cryptographic Hashing. For the purposes of this comparison, the essential point is simply that hashing goes one way and involves no secret.

One critical nuance: "one-way" does not mean "safe for weak inputs." If someone hashes the word summer2024, nobody has to reverse anything — they hash a dictionary and look for a match. This is why passwords need slow, salted hashes such as Argon2 or bcrypt rather than SHA-256, and why the choice of hash function for passwords is a different decision than the choice for file integrity.

Choosing the Right One

Work through these questions in order and the answer falls out.

Do you need the original data back later? If no, hash it. Password verification, file integrity checks, deduplication keys, and commit identifiers all fall here. If yes, continue.

Does it need to be hidden from anyone who can see it in transit or at rest? If no, encode it. Embedding an image in a data URI, putting binary in JSON, or making a value URL-safe are all encoding jobs. If yes, encrypt it.

If encrypting, who needs to decrypt? Just you, or parties who already share a secret with you: symmetric, AES-256-GCM. Someone you have never exchanged a secret with: asymmetric, or asymmetric to wrap a symmetric key.

Real Scenarios

Scenario	Correct choice	Why
Storing user passwords	Argon2 or bcrypt (slow hash + salt)	You never need the password back, only to check it
Storing customers' credit card numbers	Encryption (AES-256-GCM)	You need the value back to process payments
Putting a PNG inside a JSON payload	Base64 encoding	Compatibility problem, not a secrecy problem
Verifying a downloaded installer	SHA-256 hash comparison	Detect any modification without a shared secret
API token in a query string	Encoding for transport, HTTPS for secrecy	Encoding makes it URL-safe; TLS makes it private
Session cookie contents	Encryption plus an authentication tag	Must be readable by the server and unforgeable by the client
Sending a file to someone you have not met	Asymmetric to exchange a key, then symmetric	Solves key distribution and bulk speed together

Common Anti-Patterns

"We Base64 the password before sending it." This provides zero protection. Use HTTPS, and never transmit or store reversible passwords.

"We encrypt passwords in the database." Anyone who obtains the key obtains every password. Hash them instead.

"We hash the credit card number so it's secure." Card numbers have low entropy and a known format; every possible value can be enumerated and hashed. Encrypt, or better, do not store them at all.

"We wrote our own cipher so attackers can't reverse it." Custom cryptography fails, without exception, on a timeline measured in days. Use AES-GCM through a vetted library.

"AES-CBC is fine, it's still AES." Without a correctly applied MAC, CBC ciphertext can be tampered with in ways that leak plaintext. Use GCM.

Why Client-Side Matters Here

There is a structural irony in most online crypto tools: to encrypt something on a typical website, you upload your plaintext to a stranger's server. The secret you were trying to protect has already left your control before the encryption happens.

Every tool referenced in this guide runs entirely in your browser using the Web Crypto API. Your plaintext, your keys, and your files are processed on your own device and never transmitted anywhere. That is not a marketing line — it is the only architecture under which pasting sensitive data into a web tool is a defensible thing to do. You can disconnect from the network and every one of these tools still works.

Conclusion

The three transformations are not competing options on a strength scale. They answer three different questions. Encoding asks can this data travel through this channel intact? Encryption asks can this data be kept from anyone without the key? Hashing asks is this data still exactly what it was?

Get the question right and the tool is obvious. Encode when the problem is format. Encrypt when the problem is confidentiality and you need the data back. Hash when you need to verify without retaining. And whenever you see Base64 being described as security, you have found a bug worth filing — start with the Base64 Encoder / Decoder to demonstrate exactly how little protection it offers.