Hashes, Checksums and Encryption — Explained Without the Jargon

Three words get used interchangeably in every security conversation, and they mean completely different things. Encoding is a format change anyone can reverse (Base64 is not security — see our Base64 guide). Encryption is a lockbox: reversible, but only with the key. Hashing is a fingerprint: irreversible by design, and the same input always produces the same one.

Confusing them isn't academic — it's how passwords end up "protected" with Base64 and how "encrypted" gets claimed by things that aren't. Ten minutes here inoculates you permanently.

Hashing: the fingerprint

A hash function digests any input — a word, a 4GB file — into a fixed-length string like a591a6d4.... Three properties make it useful: the same input always yields the same hash; a one-bit change produces a completely different hash; and you cannot run it backwards to recover the input.

Hash Generator computes MD5, SHA-1, SHA-256 and friends from text or files, locally. Which to use is settled: SHA-256 for anything that matters today; MD5 and SHA-1 survive only for legacy compatibility checks, as collisions have broken them for security purposes.

The killer app: verifying downloads

Software sites publish a checksum next to the download button for a reason: if your downloaded file's hash matches theirs, the file arrived *bit-perfect* — not corrupted mid-transfer, not tampered with by a mirror. The ritual:

1. Download the file; copy the site's published SHA-256.
2. Drop the file into Hash Generator — hashing a large file happens locally, so nothing uploads.
3. Compare. Match = proceed; mismatch = delete and re-download from the official source, no exceptions.

Same trick works for your own archives: hash the backup when you store it, re-hash when you restore it years later — silent corruption has no defense against a fingerprint.

Encryption: the lockbox

Encryption transforms data so only the key-holder can read it — reversible, deliberately. File Encryption encrypts any file with a password using AES-256 (the standard governments and banks settle on), running on your browser's built-in Web Crypto API — the same vetted cryptographic engine that secures HTTPS, not homemade math.

When it earns its keep: financial documents crossing email, backups heading to cloud storage you half-trust, anything sensitive on a USB stick that will eventually be lost. Send the encrypted file through any channel; share the password through a *different* one (file by email, password by call — never both together).

The honest warning that comes with real encryption: lose the password, lose the file. There's no recovery flow, because a recovery flow would be a backdoor. That's the feature.

Passwords and hashes: why sites never "email you your password"

Legitimate systems store only the *hash* of your password — at login, they hash what you typed and compare fingerprints. A breach leaks hashes, not passwords... unless passwords are weak enough to guess-and-hash (this is why length wins — the full argument lives in our password guide, and Password Strength Checker shows where yours stands, locally, without transmitting it anywhere).

Any service that *can* email you your actual password is storing it wrong. That's your cue to leave.

Why "local" is the entire point for these tools

Reread what these tools handle: files worth encrypting, passwords worth checking. Pasting those into a server-side website inverts the security you came for. Everything in the Security & Privacy collection runs in your browser via Web Crypto — verifiable by the airplane-mode test — which is the only architecture where a security tool isn't itself the risk.

Frequently Asked Questions

Can a hash be "decrypted"?

No — hashing discards information irreversibly. Attackers instead *guess* inputs and compare hashes, which succeeds only against weak inputs. Fingerprints identify; they don't contain.

Is browser encryption as strong as desktop software?

The algorithm (AES-256 via Web Crypto) is identical to what desktop tools use — strength lives in the algorithm and your password, not the installation format.

MD5 shows a match — is my download safe?

Matching MD5 confirms *integrity* (no corruption) but not *security* — collisions are forgeable. Fine for checking a transfer; insist on SHA-256 when tampering is the concern.

What should I encrypt, practically?

The shortlist: ID-document scans, financial records leaving your machine, backup archives, and anything you'd mind a lost-laptop stranger reading. Thirty seconds each with File Encryption.

Verify one download, encrypt one sensitive file — start at Hash Generator — and the concepts stick better than any glossary — full kit at Security & Privacy.