Compare the digest, do not store a password in one
I hash strings here when I need a fingerprint I can compare: a published SHA-256 on a release note, an old CDN cache key, a “did this JSON actually change” check. I do not hash passwords here and then store the hex. SHA-256(password) is still a fast hash. Password storage wants a slow KDF with a salt — Argon2, bcrypt, or scrypt on the server. This page will happily digest whatever you type. That is not permission to treat the output as a credential store.
What this is not: encryption (you cannot reverse a digest to get the original on purpose), HMAC (there is no key field), or a file hasher. Paste text. A 200 MB installer belongs in sha256sum on the machine, not in a textarea. MD5 and SHA-1 are on the page because old pipelines still emit them. They are fine as “does this equal that” checksums. They are the wrong tool for integrity under an attacker or for anything that used to be a password.
Worked example: the avalanche on “hello”
Paste hello. SHA-256 is 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. MD5 is 5d41402abc4b2a76b9719d911017c592. SHA-1 is aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434b. Add a bang: hello!. Every algorithm flips to a completely different hex string. That avalanche is the feature. If two “different” inputs ever share an MD5, you have a collision, not a coincidence you can ignore for security work.
Worked example: the trailing newline that fails CI
Your GitHub Actions log prints SHA-256 of a file that ends in a newline. You paste the visible characters into this box and omit the newline. Digests disagree. Same trap with a UTF-8 BOM on a Windows export, or with hello versus hello (trailing space). For JSON, {"rate":18} and {"rate": 18} are different bytes and different hashes even when JSON.parse agrees. If you are checksumming a GST e-invoice payload against a vendor’s published digest, hash the exact bytes they hashed, not the pretty-printed version.
Worked example: MD5 as a cache key, not as a lock
Some Indian CDN and CMS stacks still key fragment caches on MD5 of a URL or of a template string. hello world → MD5 5eb63bbbe01eeed093cb22bb8f5acdc3. That is a lookup key. It is not proof the object is authentic. Chosen-prefix MD5 collisions are a research result, not a trivia question. If the decision is “may this user log in” or “is this package untampered versus a nation-state,” do not use MD5. Prefer SHA-256 and, for packages, a signature — a hash alone does not name the publisher.
Limits of this box
Empty string SHA-256 is the well-known e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. If you see that, you hashed nothing. This page loads CryptoJS from a CDN, then digests in the tab; if the library has not arrived, the buttons error. Unicode is hashed as UTF-8 text you pasted, not as a hex dump of a binary. HMAC-SHA256 with a secret is a different construction and is not offered, on purpose: a keyed hash in a webpage is how people leak the key.
Questions
Is SHA-256(password) acceptable storage?
No. It is fast and unsalted here. Use Argon2, bcrypt, or scrypt with a unique salt on the server.
Why does my digest disagree with sha256sum?
Different bytes. Newlines, a BOM, or hashing the filename instead of the contents are the usual three. This page hashes the textarea, not a file on disk.
When is MD5 still reasonable?
As a non-security checksum or a legacy cache key. Not for passwords, not for “this download is authentic,” not for collision-resistant identifiers.
Can I get the original string back from SHA-256?
Not by design. Rainbow tables and guessing work on short or common inputs. High-entropy input stays one-way.
Does this compute HMAC?
No. HMAC needs a key handling story I will not put in a textarea next to a digest button.
The MD5 button says the library is missing — is my string on a server?
No. CryptoJS is fetched so the digest can run in-page. Until it loads, nothing hashes. The string stays in the box.