Encoding vs Encryption vs Hashing: The Difference, With Examples

Three strings, all produced from the word hello:

Base64:   aGVsbG8=
SHA-256:  2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
AES-GCM:  (different every time — depends on the key, salt and IV)

They all look like noise, which is exactly why the three ideas get confused — in bug reports, in job interviews, and in production code that "encrypts" passwords with Base64. The difference is not how the output looks. It is who can reverse it, and with what.

Encoding: changing the format, not hiding anything

Encoding maps data from one representation to another using a public, fixed rule. Base64 exists because many channels — email, JSON, URLs, HTTP headers — were built for text and mangle raw bytes. Base64 takes every 3 bytes and writes them as 4 characters from a 64-character alphabet, so binary survives the trip. Hex does the same with 2 characters per byte.

Because the rule is public and there is no key, decoding is always possible for anyone. Paste aGVsbG8= into the Base64 decoder and you get hello back instantly. That is the whole point: encoding is about compatibility, not confidentiality.

Common encodings you will meet:

• Base64 / Base64URL — binary in text channels; Base64URL is the URL-safe variant used inside JWTs.
• Hexadecimal — how hashes, keys and raw bytes are usually displayed to humans.
• URL (percent) encoding — escapes characters like spaces and & inside URLs.
• Base32, Base58, Base85 — TOTP secrets, Bitcoin addresses, PDF streams.
• UTF-8 — itself an encoding, from Unicode characters to bytes.

Encryption: reversible, but only with the key

Encryption transforms plaintext into ciphertext using an algorithm and a secret key. The algorithm is public — AES has been published since 1998 — and the security rests entirely on the key. Without it, recovering the plaintext is computationally infeasible; with it, decryption is instant.

There are two families:

• Symmetric encryption uses one shared key to encrypt and decrypt. AES and ChaCha20-Poly1305 are the modern standards. They are fast enough to encrypt gigabytes per second and protect everything from HTTPS traffic to your phone's storage.
• Asymmetric (public-key) encryption uses a key pair: anyone can encrypt with the public key, only the private key decrypts. RSA and elliptic-curve schemes solve the problem of sharing a key with someone you have never met. In practice they encrypt a random symmetric key, which then encrypts the data — this is how PGP and TLS work.

A property that surprises people: good encryption produces different output every time, even for the same message and password. Our AES tool generates a fresh random salt and IV per encryption. If the same input always produced the same ciphertext, an attacker could tell when you sent the same message twice — a leak that the old ECB mode famously suffers from.

Modern encryption should also be authenticated (AEAD): AES-GCM and ChaCha20-Poly1305 attach a tag that detects tampering. Unauthenticated modes like AES-CBC keep data secret but let an attacker flip bits undetected. Our guide to AES modes covers why this matters.

Hashing: a one-way fingerprint

A cryptographic hash function takes input of any size and produces a fixed-size digest. SHA-256 always outputs 256 bits (64 hex characters), whether you hash one letter or a 4 GB ISO. Three properties make it useful:

• Deterministic — the same input always gives the same hash, so two parties can compare fingerprints.
• Avalanche effect — change one bit of input and about half the output bits flip.
• One-way and collision-resistant — you cannot find an input for a given hash, or two inputs with the same hash, in any practical amount of time.

The avalanche effect is easy to see. Change one character and the digests share nothing recognisable:

$ printf 'hello' | sha256sum
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  -
$ printf 'Hello' | sha256sum
185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969  -

There is no key and nothing to "decrypt". So-called hash decrypters are lookup tables of hashes of common strings: they find hello because someone hashed hello before, not because the hash was reversed. That is also why an unsalted fast hash of a weak password offers little protection.

Where hashes are used:

• Integrity checks — publishers list a SHA-256 checksum so you can verify a download.
• Digital signatures — you sign the hash of a document, not the whole document.
• Content addressing — Git names every commit and file by its hash.
• Message authentication — HMAC mixes a secret key into a hash so only key holders can produce a valid tag; this is how webhook signatures and HS256 JWTs work.

The special case: storing passwords

Passwords are where the confusion does the most damage, so it is worth being precise:

• Encoding passwords (Base64) is equivalent to storing them in plaintext.
• Encrypting passwords is almost always wrong: whoever steals the database usually steals the key too, and then every password is exposed at once. The server never needs to recover a password — only to check it.
• Hashing with SHA-256 or MD5 is better but still weak. These are designed to be fast; a single modern GPU computes tens of billions of them per second, so short passwords fall quickly.
• Hashing with a password hashing function is correct. Argon2id, scrypt and bcrypt add a unique salt and are deliberately slow and memory-hungry, cutting attacker throughput by many orders of magnitude.

Our comparison of Argon2id vs bcrypt vs scrypt vs PBKDF2 gives current recommended parameters.

How to tell which one you are looking at

When you meet an unknown string in a log, token or database, a few signs help:

• Ends in `=` or `==`, uses A–Z a–z 0–9 + / — almost certainly Base64. Decode it and see.
• Exactly 32, 40, 64 or 128 hex characters — probably an MD5, SHA-1, SHA-256 or SHA-512 hash.
• Starts with `$2b$`, `$argon2id$` or `$scrypt$` — a password hash in modular crypt format. The parameters and salt are stored right in the string.
• Three Base64URL segments separated by dots — a JWT. Its contents are encoded, not encrypted; paste it into the JWT decoder to read it.
• Random-looking, changes every time the same data is processed, length tracks the input — likely encryption with a random IV.