User Guide
Type or paste your text
The hash updates from whatever is in the box. Every character counts — a single trailing space produces a completely different result.
Choose an algorithm
MD5, SHA-1, SHA-256 or SHA-512. For anything where the answer matters, pick SHA-256. MD5 and SHA-1 remain here because file checksums and legacy systems still use them, not because they are safe.
Read the digest
Output is hexadecimal and always a fixed length for a given algorithm — 32 characters for MD5, 64 for SHA-256 — no matter how much text went in.
Compare, do not eyeball
To check a download against a published checksum, paste both into a text editor or the Text Diff Checker. Comparing 64 hex characters by eye is how mismatches get missed.
Note the avalanche effect
Change one letter and the entire digest changes. That is by design, and it is what makes hashes useful for detecting alteration — but it also means a hash cannot tell you how much changed.
Do not use this for passwords
General-purpose hashes are built to be fast, which is exactly wrong for password storage. Use bcrypt, scrypt or Argon2 with a per-user salt instead. The section below explains why.
About the Hash Generator
A cryptographic hash turns any input into a fixed-length fingerprint. The same input always gives the same output; any change gives a completely different one; and the process cannot be reversed. This tool computes MD5, SHA-1, SHA-256 and SHA-512 in your browser using the standard Web Crypto digest API for the SHA family.
Hashing is not encryption
This is the distinction that matters most, and it is regularly confused.
Encryption is two-way. It scrambles data with a key so that someone holding the key can recover the original.
Hashing is one-way. There is no key and no route back. A hash is a fingerprint, not a container — the original data is not inside it in any form. That is what makes hashing useful for verification and useless for storage. You cannot “decrypt” a hash. Sites claiming to do so are running a lookup table of previously computed values, which works only for common inputs.
Which algorithm to use
| Algorithm | Digest | Status | Use it for |
|---|---|---|---|
| MD5 | 128-bit, 32 hex | Broken | Legacy checksums only |
| SHA-1 | 160-bit, 40 hex | Broken | Legacy systems only (Git, older TLS) |
| SHA-256 | 256-bit, 64 hex | Secure | The sensible default |
| SHA-512 | 512-bit, 128 hex | Secure | Longer digest; faster on 64-bit hardware |
“Broken” here has a precise meaning: researchers can construct two different inputs producing the same digest. For MD5 this has been practical for years, and RFC 6151 formally documents it as unsuitable for security use. For SHA-1, the SHAttered collision (2017) demonstrated a real collision between two distinct PDF files.
A collision defeats the entire point of a signature or an integrity check — an attacker can substitute a different file with a matching hash. Both algorithms are kept here because you will still meet them: many projects publish MD5 checksums, and Git uses SHA-1 internally. Use them to verify against an existing published value, never to secure something new. SHA-256 and SHA-512 are specified in NIST FIPS 180-4 and remain sound.
Why never for passwords
MD5, SHA-1 and the SHA-2 family are designed to be fast. Modern hardware computes billions of SHA-256 hashes per second. Against a stolen database that speed belongs entirely to the attacker: a brute-force run through every plausible password becomes cheap.
Password hashing needs the opposite property. bcrypt, scrypt and Argon2 are deliberately slow and memory-hungry, with a tunable cost factor that can be raised as hardware improves. They also apply a unique per-user salt, so two people with the same password get different stored values and one precomputed table cannot break both. The OWASP password storage guidance and NIST SP 800-63B both set this out.
Use this tool to verify a download, check that a file transferred intact, or generate a deduplication key. Do not use it to store credentials.
Verifying a download
The common case: a project publishes a SHA-256 checksum next to a file. After downloading, hash your copy and compare. Matching digests mean the file arrived intact and unmodified.
One caveat worth stating. If an attacker controls the page serving both the file and the checksum, they can change both. A checksum proves the file matches what that page claims — not that the page is honest. Real protection comes from a signature verified against a key you already trust.
Privacy
Everything runs in JavaScript inside this page. Nothing you type is transmitted, logged or stored.
Frequently Asked Questions
Can I decrypt or reverse a hash?
No. Hashing is one-way by design — the original data is not inside the digest in any form. Sites offering to “decrypt” a hash are searching a table of previously computed values, which only works for common inputs like short or popular passwords.
Which algorithm should I use?
SHA-256 for anything that matters. MD5 and SHA-1 are cryptographically broken — researchers can construct two different inputs with the same digest — and are offered here only for verifying against existing published checksums and legacy systems.
Why should I not hash passwords with SHA-256?
Because it is fast, and speed helps the attacker. Modern hardware computes billions of SHA-256 hashes per second, making brute force against a stolen database cheap. Use bcrypt, scrypt or Argon2, which are deliberately slow, memory-hard and salted per user.
What does it mean that MD5 is “broken”?
That collisions are practical: two different inputs can be constructed to produce the same digest. RFC 6151 documents this. It defeats the purpose of a signature or integrity check, since a different file can be substituted with a matching hash.
Is SHA-1 still safe?
No. The SHAttered research in 2017 produced two distinct PDF files with an identical SHA-1 digest. It survives in Git and some legacy systems for compatibility, but should never be chosen for new security work.
Why does changing one letter change the whole hash?
This is the avalanche effect, and it is intentional. A small input change must produce an unpredictably different output, otherwise similar inputs would produce similar digests and the hash could be attacked by working backwards.
What is a salt?
A unique random value combined with each password before hashing. It ensures two users with the same password get different stored hashes, so a single precomputed table cannot break multiple accounts at once. Proper password hashing functions handle salting for you.
Is my text sent to a server?
No. Hashing runs in JavaScript inside this page, using the browser’s built-in Web Crypto API for the SHA algorithms. Nothing you type is transmitted or stored.