How to use it
- Type or paste text into the input panel.
- Tick the algorithms you want. Digests appear immediately.
- The status bar shows the byte count that was actually hashed.
What a hash is for
A cryptographic hash maps any input to a fixed-length digest with three properties: the same input always gives the same output, a one-character change gives a completely different output, and you cannot work backwards from the digest.
That combination makes hashes useful for integrity above all. Publish the SHA-256 of a download and anyone can verify their copy is byte-identical. Store a hash of a file and you can detect modification without keeping the file. Git identifies every object by its hash, which is how it knows two files are the same without comparing them.
What a hash is not is encryption. There is no key and no decryption — the input is not recoverable, by you or anyone. If you need to get the data back, you need encryption instead.
Why MD5 and SHA-1 are still here
Both are broken in a specific sense: it is now practical to construct two different inputs with the same digest. MD5 collisions can be generated in seconds; the first SHA-1 collision was demonstrated in 2017 and the cost has fallen steadily since.
A collision matters whenever someone might want two inputs to look identical — a signature, a certificate, a content-addressed store where a malicious file could impersonate a good one. In those settings MD5 and SHA-1 are unusable.
They are, however, still fine where no adversary is involved. Verifying that a file transferred without corruption, generating a cache key, or checking whether a row changed since last night are all non-adversarial uses, and a great deal of existing software still emits MD5 for exactly that. This tool includes them for interoperability, with the warning attached.
Hashing passwords: don't use these
This is the most consequential misuse, so it is worth being blunt about it.
SHA-256's design goal is speed. That is a feature for checksums and a catastrophe for passwords: an attacker who obtains your hash file can test billions of candidates per second on commodity GPUs, and most human-chosen passwords fall quickly. Adding a salt prevents precomputed rainbow tables but does nothing about raw speed.
Password hashing needs functions built to be slow and memory-hungry, with a tunable cost parameter: bcrypt, scrypt, or Argon2id. Each one salts automatically and lets you raise the cost as hardware improves. In .NET, ASP.NET Core Identity's PasswordHasher uses PBKDF2 with a high iteration count, which is acceptable; Argon2id is the current recommendation for new systems.
Encoding is where surprises come from
A hash is computed over bytes, not characters. "café" in UTF-8 is five bytes; in UTF-16 it is eight. Same string, different digest.
This tool hashes the UTF-8 encoding of exactly what is in the input box, and reports the byte count so you can check it against expectation. When a digest fails to match a value from elsewhere, the cause is almost always one of three things: a trailing newline, the file being UTF-16 or having a BOM, or CRLF line endings where the other side used LF.