Hash vs Encryption: What Is the Difference?

Hash and encryption are the two security operations people mix up most, and the mix-up usually ends with data stored in the wrong form. The difference fits in one sentence: a hash is a one-way fingerprint that cannot be reversed, and encryption is a reversible transformation guarded by a key. Everything else - password storage, integrity checks, data at rest - follows from that. The NIST guidelines on hash functions are the reference this article follows.

What is the core difference?

Hashing takes any input and produces a fixed-length digest. The operation is one-way, so you cannot work back from the digest to the input, and it is deterministic, so the same input always gives the same digest. Encryption takes input plus a key and produces ciphertext, and decryption with the correct key restores the original exactly. One destroys information, the other preserves it behind a key. The choice of which to use is decided by the question you are answering: do you need to prove something did not change, or do you need to keep it readable only to the key holder?

Can a hash be reversed?

No, not in the direction you might hope. A hash function has no inverse, so there is no operation that turns a digest back into its input. Attackers instead guess candidate inputs, hash them, and compare - which is what a brute force attack is - and they speed up the guessing with rainbow tables that precompute digests of common passwords. Two defenses cancel those tricks: a random salt makes each stored digest unique, and a deliberately slow hashing algorithm such as bcrypt, scrypt or argon2 makes each guess expensive. Fast general-purpose hashes such as SHA-256 are for integrity, not for passwords.

How are hashes used?

• Integrity checks: the SHA-256 digest of a downloaded file proves the bytes are exactly what the publisher shipped.
• Password storage: a salted, slow hash of the password is stored, and a login is accepted by hashing the attempt and comparing digests.
• Deduplication: identical content produces identical digests, so storage systems and version control can spot repeats.
• Keyed verification: HMAC, a hash with a secret key, proves both integrity and that the message came from someone holding the key.

The unifying idea is a fingerprint. You compare digests rather than the data itself, and because a tiny change in the input flips the digest completely, a mismatch reliably means the data changed.

How is encryption used?

• Data at rest: whole disks, databases and backups are encrypted so a stolen drive yields nothing readable without the key.
• Data in transit: TLS encrypts the connection between a browser and a server, so the bytes crossing the wire are unreadable to eavesdroppers.
• Symmetric encryption: one shared secret both encrypts and decrypts, which is fast and used for most bulk data.
• Asymmetric encryption: a public key encrypts and a private key decrypts, which lets anyone send a secret to the key holder.

Encryption is about confidentiality: making data unreadable without the key, and recovering it intact when the key is present. That reversibility is the feature, and it is also why encryption is the wrong tool for the one job where reversibility is dangerous, which is storing passwords.

Why hash passwords instead of encrypting them?

An encrypted password is reversible, so the key becomes a single point of failure. If the database and the key are both stolen, every password is recovered, and users who reuse the password across sites are exposed everywhere. A hashed password cannot be reversed, so a leaked database yields digests, not passwords, and the digests are expensive to crack when salted with a slow algorithm. Reversibility is exactly the property you do not want in password storage, which is why encryption is never the right choice there.

What is a salt?

A salt is a random value added to the password before hashing, unique per user and stored next to the digest. It does not make a single hash harder to compute; it makes every hash different, so two users with the same password produce different digests, and an attacker cannot reuse one precomputed table across the whole database. The practical rule is to always use a random per-user salt and a password-hashing algorithm designed for the job, never a plain fast hash.

What is HMAC and how does it differ?

HMAC is a hash computed with a secret key: HMAC(key, message). Unlike a plain hash, it cannot be recomputed by anyone who does not hold the key, so it proves both that the message is intact and that the key holder produced it. That makes it the standard way to authenticate messages between services - webhook payloads, API signatures, JWT signatures - where you want integrity plus authenticity, without encryption. The HMAC Generator computes one for a given key and message.

How do you generate a hash or ciphertext?

The Hash Generator computes common digests such as MD5, SHA-1 and SHA-256 for any input, and the HMAC Generator does the keyed variant. For a live experiment, hash a sentence, change one character, and hash again - the digest changes completely, which is the fingerprint property in action. To see the other side of the fence, the base64 guide shows an encoding, and its FAQ explains why encoding, hashing and encryption are three different tools that do not substitute for one another.