A hash function turns any input into a fixed-length fingerprint. The same input always gives the same output, and changing one bit changes the result completely. This tool computes MD5, SHA-1, SHA-256, SHA-384 and SHA-512 — but which of those you should reach for depends entirely on what you are trying to prove.
Hashing is one-way, and that is the point
Unlike encoding or encryption, hashing has no reverse. There is no key that turns a SHA-256 digest back into the file it came from, because the digest is 32 bytes no matter whether the input was a word or a gigabyte — most of the information is simply gone. When a site claims to "decrypt" an MD5 hash, it is looking the value up in a table of pre-computed hashes of common inputs. That works for "password123" and fails for anything unpredictable.
That property is what makes hashes useful for comparison. You can prove two files are identical, or that a download was not corrupted, without ever handling the files together.
MD5 and SHA-1 are broken — for some purposes
Both are broken in a specific sense: collision resistance. A collision is two different inputs producing the same digest, and for MD5 an attacker can construct one in seconds on a laptop. SHA-1 fell in 2017 when researchers produced two different PDFs with the same digest, and by 2020 chosen-prefix collisions made it practically attackable. If a hash is meant to prove that a document is the document you signed, neither is fit for the job.
They are not, however, useless. Checking that a file survived a network transfer intact is a question about accidental corruption, not a malicious adversary, and MD5 answers it fine — which is why plenty of tooling still emits MD5 checksums. The rule is simple: if an attacker would benefit from making two inputs collide, you need SHA-256. If nobody is attacking you and you just want to notice a flipped bit, MD5 is fast and adequate.
Never hash a password with these
This is the mistake that turns a database leak into a catastrophe. SHA-256 is designed to be fast — modern hardware computes billions of them per second. That speed is a virtue for checksums and a fatal flaw for passwords, because it is exactly what an attacker with your leaked hash table wants. Adding a salt stops precomputed rainbow tables but does nothing about raw speed.
Password hashing needs a function that is deliberately slow and memory-hungry: bcrypt, scrypt or Argon2. They take a tunable cost parameter so you can make each guess expensive, and Argon2 additionally demands large amounts of memory to frustrate GPU attacks. If you are reaching for a hash to store a password, none of the algorithms on this page are the right answer.
Why MD5 works here but is not in the browser API
The SHA algorithms on this page run through the browser's built-in Web Crypto API. MD5 does not, because Web Crypto deliberately refuses to implement it — the standards body chose not to hand developers a broken primitive. So MD5 here is computed by JavaScript written for the purpose.
One consequence worth knowing: Web Crypto is only available in a secure context. Over plain HTTP on a non-localhost address, crypto.subtle is undefined and the SHA options simply cannot work, while MD5 keeps going. If you ever see a hash tool where MD5 works and SHA-256 does nothing, that is almost certainly why.
Common questions
Is my input sent to a server?
No. This tool is marked "client": the digest is computed in your browser tab and the input never leaves your machine. Worth stating plainly because hashing is often reached for with sensitive material — but if the input is genuinely sensitive, use a tool your organisation controls rather than any free web page, this one included.
Can I recover the original text from a hash?
No, and no tool can. What "reverse MD5" sites actually do is look your digest up in a dictionary of pre-computed hashes. If your input was a common word or a leaked password they will find it instantly; if it was anything unpredictable they will find nothing. The hash itself contains no path back.
Which one should I use?
SHA-256 unless you have a specific reason not to. It is fast enough for anything interactive, has no practical attacks, and is what the rest of the ecosystem expects. Use MD5 only when something else demands it — an existing checksum file, a legacy API — and never for anything an attacker benefits from breaking.
Why does the same text give a different hash than my server?
Almost always a difference in what is being hashed rather than how. A trailing newline is the classic culprit: echo adds one, so echo "abc" | md5sum hashes four bytes, not three. Character encoding is the other one — the same visible text in UTF-8 and UTF-16 is a different sequence of bytes and therefore a different digest. Hashes have no tolerance for "nearly the same input".
Is a longer hash more secure?
Only against brute force, and SHA-256 already puts that far beyond reach. SHA-512 is not meaningfully safer than SHA-256 for ordinary use — on 64-bit hardware it is often slightly faster, which is the more common reason to pick it. Length is not the axis that matters; whether the algorithm has known attacks is.