Hash Generator

What this tool offers, and what it deliberately does not

That absence is worth being blunt about, because MD5 is the algorithm people arrive looking for. Collisions in MD5 are trivial to produce — two different inputs with the identical digest can be generated on a laptop — so it cannot prove that anything is unaltered. It survives only as a legacy identifier in systems nobody updated. Everything here instead runs through crypto.subtle.digest, the hashing primitive built into the browser, which is also why the page has to be served over HTTPS or localhost: that API is unavailable outside a secure context, by browser rule.

Which hash for which job

The digest length in the middle column is a useful diagnostic on its own. If you are handed a 40-character hex string and told it is a SHA-256 checksum, someone is mistaken about which algorithm produced it.

Matching the command line exactly

Type hello into the field above and put the same five characters through a shell with printf 'hello' | sha256sum. The digests are identical. Now run echo hello | sha256sum instead and it is completely different — because echo appends a newline, and a newline is another byte of input.

This is the single most common reason a hash "does not match" when nothing is actually wrong. This tool hashes precisely the bytes in the textarea, encoded as UTF-8, with nothing added: no trailing newline, no trimmed whitespace, no Unicode normalisation. One catch: a browser text box stores line breaks as LF, so text copied from a Windows file with CRLF line endings hashes differently from the file itself. Compare like with like and the mismatch disappears.

While you are in there, delete one character and watch all four digests change completely rather than partially. A hash is not a summary that drifts as the input drifts; a one-bit change rewrites the whole output. That is why comparing the first eight characters of two digests is a reasonable shortcut for a human eyeballing a match, and never acceptable in code.

The limit on this page: it hashes text you paste, not files. There is no file input, so you cannot verify the checksum of a downloaded installer here. Use the tool on your own machine for that — sha256sum, shasum -a 256, or Get-FileHash in PowerShell — which is the right place for it anyway, since the point is to check the copy that landed on your disk.

SHA-256 is not password storage, and not anonymisation

Passwords. Hashing is one-way, so storing SHA-256(password) instead of the password itself feels like the responsible thing to do. It is not enough. SHA-256 is designed to be fast, and speed is the attacker's ally: given a stolen table of digests, guesses can be tried at enormous rates until the common passwords fall out. Password storage needs a function that is deliberately slow and memory-hungry, with a unique random salt per user, so every stolen record has to be attacked separately. That means a password-hashing scheme such as Argon2id, scrypt, bcrypt or PBKDF2 with a high work factor. A raw SHA digest, salted or not, is not a substitute. The useful thing you can do from this side is stop reusing guessable passwords in the first place — the password generator draws from crypto.getRandomValues rather than Math.random, so its output is not predictable from the time you clicked.

Identifiers. Hashing is deterministic, which means a low-entropy input is not protected by being hashed. Hash an email address and anyone with a list of candidate addresses can hash the same list and match yours exactly. Hash a phone number and the entire space is small enough to enumerate outright. This is why "we only store hashed emails" is a weak privacy claim: the hash is a stable identifier, not an anonymisation. If you genuinely need a random label with no relationship to the underlying value, generate one — that is what the UUID generator is for.

Authenticity. A bare hash sent alongside a message proves nothing about who sent it, because anyone who can alter the message can recompute the hash. Proving origin needs a key in the calculation, which is what HMAC does. This tool does plain digests only. And if your real requirement is that a third party cannot read the content, that is encryption, not hashing — a different operation with a different tool.

You are usually hashing the sensitive value itself

Think about why anyone opens a hash generator. Checking whether a value in a database matches one you hold. Reproducing a signature an API rejected. Hashing an API key to compare it against a stored fingerprint. In every case the interesting input is the secret — and a remote hasher receives that secret in full, hashes it on someone else's CPU, and sends back a digest you could have computed locally. The digest is not the sensitive part. The thing you typed is.

Nothing is transmitted from this page. The script reads the textarea, passes the bytes to the browser's own crypto implementation, and prints hex; there is no fetch, no XMLHttpRequest and no analytics call anywhere in it. Disconnect from the network and every field still updates as you type. The same holds for the Base64 encoder and the JWT decoder, which is the whole reason to keep this set of developer tools in one place.