Hash Generator_
Type text or choose a file and every digest appears at once — MD5, SHA-1, SHA-256, SHA-384 and SHA-512. All five are shown together because the usual job is checking a checksum somebody sent you, and the length is often the only clue to which algorithm they used.
A hash cannot be turned back into its input. There is no key, no reverse function, and nothing this or any other page can do about it — so if you arrived looking to decrypt or unhash something, the section below explains what the services that claim to do it are really doing, and when it works.
—————- Input
- Any text, or any file. A file is read in the page and hashed from its bytes, which is the only way a checksum means anything — hashing a filename would tell you nothing.
- Output
- Five digests at once, in lowercase hexadecimal by default. Uppercase is the same value written differently and compares equal.
- Processing
- SHA comes from the browser's own Web Crypto implementation. MD5 is not in Web Crypto — deliberately, because it is broken — so it is implemented in the page and checked against the seven test vectors printed in RFC 1321.
- Limits
- No key, no salt, no iteration count. These are plain digests, which is what a checksum needs and emphatically not what a password needs.
- Never hash a password with these
- SHA-256 is fast, and speed is the enemy here — commodity hardware computes billions of SHA-256 digests a second, so a stolen table of them falls to a dictionary attack quickly. Passwords want bcrypt, scrypt or Argon2, which are deliberately slow and individually salted. A fast hash is the right tool for integrity and the wrong tool for secrets.
You cannot decrypt a hash, and here is why
Hashing is not encryption
Encryption is reversible by design: it takes a key, and the same key brings the message back. Hashing takes no key and produces a fixed-length digest from an input of any length — a gigabyte and a single letter both come out as 64 hexadecimal characters under SHA-256. Information has been destroyed, permanently and on purpose. There is no reverse function to write, no key to find, and no algorithm anybody could discover that would change that, because the output is simply smaller than the input.
What a "hash cracker" actually does
It looks the digest up. Sites offering to decrypt MD5 have precomputed the digests of hundreds of millions of common strings — every leaked password, every dictionary word, every short combination — and they search that table. Give one the MD5 of password and it answers instantly, because that digest has been known for decades. Give it the MD5 of a long random string and it will never answer, no matter how long you wait. The tool is a search index wearing the costume of a decryption service.
Which is exactly why salt exists
A salt is a random value stored alongside each hash and mixed into the input before hashing, so two users with the same password get different digests and no precomputed table can cover them — the attacker would need a separate table per salt, which is the point. This is why password storage uses bcrypt, scrypt or Argon2 rather than a bare SHA: those functions handle salting for you, and are deliberately slow so that guessing costs real time.
MD5 and SHA-1 are broken, and still useful
Both are broken in the specific sense that an attacker can construct two different inputs with the same digest — MD5 cheaply since 2004, SHA-1 demonstrably since 2017, when a pair of colliding PDFs was published. That destroys them for signatures and for anything where an adversary chooses the input. It does not affect the ordinary case of noticing that a download arrived corrupted, because a transmission error is not an attacker and will not produce a collision. Use them to compare, never to trust.
Reading a checksum somebody published
The length names the algorithm: 32 hexadecimal characters is MD5, 40 is SHA-1, 64 is SHA-256, 96 is SHA-384, 128 is SHA-512. Comparing is case-insensitive — the same digest is often printed both ways — and a checksum only proves the file matches the one the publisher hashed. If an attacker can change the file they can usually change the checksum beside it, which is why signatures exist and why a checksum on the same page as the download is a convenience rather than a guarantee.
Type or choose a file, then compare
- 01Type text and all five digests appear at once. Nothing is submitted — the digests recompute on each keystroke.
- 02For a file, use the button in the toolbar. Every algorithm is computed from the same bytes in one pass, so the five digests below always describe the same thing.
- 03Paste a checksum you were given into the compare box. It says which algorithm has that length and whether it matches.
- 04Turn on uppercase when a published checksum is printed that way and you want to read the two lines against each other.
Checking a download arrived intact
The publisher lists a SHA-256 next to the file. Hashing your copy and comparing tells you whether the bytes survived the trip.
ba7816bf8f01cfea414140de5dae2223 b00361a396177a9cb410ff61f20015ad
Same 64 characters → the file is byte-identical. Different → do not run it.
Telling whether two files are the same
Two copies of a document with different names and timestamps. Their contents are identical if and only if their digests are.
d41d8cd98f00b204e9800998ecf8427e
d41d8cd98f00b204e9800998ecf8427e Identical contents, whatever the names say.
A digest you were given and cannot place
Someone sends a checksum with no algorithm named. The length is the clue, and it is unambiguous.
5d41402abc4b2a76b9719d911017c592
32 hex characters → MD5. 40 → SHA-1 · 64 → SHA-256 · 128 → SHA-512
Why a leaked password table falls quickly
Unsalted fast hashes of common passwords are already in every lookup table. This is the argument for bcrypt, made concrete.
5f4dcc3b5aa765d61d8327deb882cf99
password A long random input from the same algorithm is never found.
The five, and what each is for
| Algorithm | Digest | Status | Use it for |
|---|---|---|---|
| MD5 | 128 bits · 32 hex chars | Broken for security | Broken since 2004 — two different inputs can be made to collide on purpose, cheaply. Fine for spotting an accidentally corrupted download, useless against anyone who is trying. |
| SHA-1 | 160 bits · 40 hex chars | Broken for security | Broken in practice since 2017, when a real colliding pair of PDFs was produced. Git still uses it for object names, which is about identity rather than defence. |
| SHA-256 | 256 bits · 64 hex chars | Current | The current default for signatures, certificates and integrity checks. No practical attack. |
| SHA-384 | 384 bits · 96 hex chars | Current | SHA-512 truncated, which makes it resistant to length-extension in a way SHA-256 is not. |
| SHA-512 | 512 bits · 128 hex chars | Current | Wider digest, and faster than SHA-256 on 64-bit hardware. |
Every length in the second column is asserted in the test suite by hashing a value and measuring the result, and MD5 is checked against all seven vectors printed in RFC 1321 — the specification's own examples, so a mistake anywhere in the implementation fails the build.
Habits worth having around hashes
- Use SHA-256 unless something forces your hand. It is the current default for signatures, certificates and integrity checks, and nothing practical breaks it.
- Never store a password as a plain hash, however modern the algorithm. Use bcrypt, scrypt or Argon2 — they salt automatically and are slow on purpose.
- Let the compare box do the matching rather than reading thirty-two characters by eye. Case and stray whitespace are handled, and the eye is not reliable at that length.
- Get the checksum from somewhere other than the download page when it matters. A checksum published beside the file protects against corruption, not against whoever controls the page.
- Hash the bytes, not the filename or the path. A file that has been renamed is the same file, and a checksum that changes when you rename something is measuring the wrong thing.
Where hashes are misunderstood
There is no such thing as decrypting a hash
Services that offer it are searching a table of digests they computed earlier. They find common inputs instantly and long random ones never, and no amount of computing power changes the second half of that sentence.
A fast hash is the wrong tool for a password
SHA-256 is designed to be quick, and quick means an attacker with a stolen table can try billions of guesses per second. Password hashing functions are deliberately slow for exactly this reason.
MD5 and SHA-1 collisions are constructed, not accidental
Both are broken because an attacker can deliberately produce two inputs with one digest. That rules them out for signatures. It does not make them useless for spotting a corrupted download, where nobody is trying.
A checksum proves integrity, not authenticity
It tells you the file matches the one that was hashed. It says nothing about who hashed it. If the same party can change both the file and the checksum, you have verified nothing — that is what signatures are for.
Implementations, sources and limits
- SHA family
- The browser's own Web Crypto digest, which is a native audited implementation. Shipping another one would add risk and no capability.
- MD5
- Implemented in the page, because Web Crypto leaves it out on purpose. The specification’s own examples are used as the test suite; the MD5 page documents that verification in full.
- Input encoding
- Text is measured in UTF-8, and the byte count under the box shows what is actually being hashed — useful when a digest disagrees with one from another tool. Files contribute their raw bytes.
- Not provided
- No salt, no key, no iteration count, and no HMAC. Those belong to password storage and message authentication, which are different jobs with different tools.
- File handling
- Uploads are read inside the page with the browser File API and are never transmitted; Download writes out what is already in the tab.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about hashing, checksums and reversing
Can you decrypt or reverse a hash?
No. Hashing has no key and destroys information — any length of input becomes a fixed-length digest — so there is nothing to reverse and no algorithm anybody could invent that would change it. Services offering to decrypt MD5 or unhash SHA-256 are searching a table of digests they precomputed from common inputs.
Then why do hash crackers sometimes work?
Because the input was common. If somebody hashed the word "password", that digest has been in every lookup table for decades and appears instantly. A long random string from the same algorithm will never be found, however long the site runs, because it was never in the table and cannot be computed backwards.
What is the difference between hashing and encryption?
Encryption is two-way and takes a key: the same key returns the original message. Hashing is one-way and takes no key: it produces a fingerprint that identifies the input without containing it. Encryption is for keeping something readable later; hashing is for checking something has not changed.
Is MD5 still safe to use?
Not for anything an adversary can influence. Collisions — two different inputs with the same digest — have been constructible cheaply since 2004, which rules MD5 out for signatures or trust. It remains perfectly good for noticing that a download arrived corrupted, because transmission errors do not construct collisions.
Should I hash passwords with SHA-256?
No. SHA-256 is fast, and speed is what an attacker with a stolen database wants — commodity hardware computes billions of digests a second. Use bcrypt, scrypt or Argon2, which salt each password individually and are deliberately slow so that guessing costs real time.
How do I know which algorithm a checksum uses?
By its length. 32 hexadecimal characters is MD5, 40 is SHA-1, 64 is SHA-256, 96 is SHA-384 and 128 is SHA-512. Paste it into the compare box above and the page names it for you.
Why do two tools give different digests for the same file?
Almost always a different algorithm, or a different input than you think. Check the digest lengths first — comparing an MD5 against a SHA-256 produces a mismatch that looks like corruption. If both are the same algorithm, confirm one is hashing the file rather than a path, a filename, or text with a trailing newline the other does not have.
Does a checksum prove a file is genuine?
It proves the file matches the one that was hashed, which is integrity. It says nothing about who did the hashing. If whoever tampers with the file can also edit the checksum published beside it, nothing has been verified — authenticity requires a signature.
Is my text or file uploaded anywhere?
No. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.