Hash Generator
Hash text or a file with all five algorithms at once, and paste a published checksum to check for a match. Files are read on your device and never uploaded.
Digests
—
—
—
—
—
MD5 and SHA-1 are cryptographically broken. They remain useful for verifying a download against a published checksum, and are unsuitable for passwords, signatures, or anything an attacker might try to forge. Everything is computed on your device — a file you drop here is never uploaded.
Related tools
How to use the hash generator
- Choose text or a file. Text hashes as you type; a file is read from your device.
- Read the digests. All five algorithms compute at once, MD5 through SHA-512.
- Paste a published checksum into the compare box to verify a download. A match is highlighted and names the algorithm.
- Copy any digest you need.
Nothing is uploaded. Files are read into browser memory and hashed on your device.
When you would need this
Verifying a download. Software projects publish a checksum next to the download. Hashing the file you received and comparing proves it arrived intact.
Confirming two files are identical. Hashing both is faster and more reliable than comparing them byte by byte, especially across machines.
Checking a file has not changed. A stored hash from last month tells you whether a config file or document has been modified since.
Matching a legacy system. Older applications compare MD5 or SHA-1 digests. Reproducing them is sometimes the only way to debug an integration.
Generating a cache key. A hash of some input makes a compact, deterministic identifier.
What a hash actually guarantees
A cryptographic hash maps input of any length to a fixed-length output, with three properties that make it useful.
Deterministic. The same input always produces the same digest, on any machine, in any language, forever. This is what makes comparison possible at all.
Avalanche effect. Change one bit of the input and roughly half the output bits change. There is no partial similarity — a file with a single altered byte produces a completely unrelated hash. This is why "close enough" is not a concept in hashing.
One-way. Given a digest, there is no practical way to recover the input. Not because it is encrypted, but because information is discarded — many inputs map to each output, and the function is not designed to be inverted.
What a hash does not give you is secrecy. Hashing is not encryption. If the input is short and predictable, anyone can hash the same candidates and compare digests. Hashing an email address or a phone number does not anonymise it, which is a mistake that turns up in privacy policies more often than it should.
Why "broken" does not mean "useless"
MD5 and SHA-1 are labelled broken here, and it is worth being precise about what that means, because the label is often misapplied in both directions.
The break is collision resistance: it is possible to construct two different inputs that hash to the same value. For MD5 this takes seconds on ordinary hardware. SHA-1's first public collision was demonstrated in 2017 and has grown cheaper since.
That matters enormously where an adversary chooses the input. A signature over an MD5 hash is worthless, because someone can prepare a benign document and a malicious one sharing a digest, get the first signed, and attach the signature to the second. This is why certificate authorities abandoned both.
It matters much less for accidental corruption. A download truncated by a dropped connection will not coincidentally produce a matching MD5 — that would require deliberate construction. So an MD5 checksum still reliably detects the failure mode it was published to detect.
The practical rule: MD5 and SHA-1 are fine for verifying that a file arrived intact, and unacceptable anywhere an attacker has an incentive to forge a match. Where you have a choice, use SHA-256.
Never hash a password with these
This deserves stating bluntly, because it is the most damaging misuse of hashing and it still appears in production systems.
Every algorithm on this page is designed to be fast. That is a virtue for checksums and a catastrophe for passwords. An attacker with a stolen database of SHA-256 hashes can test tens of billions of candidates per second on commodity GPUs. A password that would survive an online login form for centuries falls in minutes offline.
Password storage requires a function that is deliberately slow and memory-hard, with a unique salt per password: bcrypt, scrypt, or Argon2. These are tuned so that a single verification takes a measurable fraction of a second, which is invisible at login and devastating to bulk guessing.
Adding a salt to SHA-256 does not fix this. Salting prevents precomputed rainbow tables; it does nothing about speed. The problem is that the function is fast, and no amount of salting makes it slow.
Limits and requirements
Text is hashed as UTF-8. The bytes hashed are the UTF-8 encoding of what you typed. A system that hashed the same text as UTF-16 or Latin-1 will produce a different digest — a common cause of "the hashes do not match" between platforms.
Whitespace counts. A trailing newline changes the hash completely. Copying a value out of a terminal often brings one along, and that is frequently the explanation for an unexpected mismatch.
Large files use memory. The file is read fully into memory before hashing. Very large files — several gigabytes — may fail on a device with limited RAM. This tool is not streaming.
MD5 is implemented locally. The SHA family comes from the browser's Web Crypto API. MD5 is implemented separately, because Web Crypto deliberately omits it, and is verified against RFC 1321's test vectors.
Browser support. Web Crypto requires a secure connection, which this site always uses. Any modern browser on desktop or mobile.
Privacy: how this tool handles your data
Text and files are hashed in your browser, on your device. Nothing is transmitted, logged or stored.
For this tool the privacy property is not incidental — it is what makes the main use case coherent. The reason to check a download's checksum is that you do not yet trust the file. Uploading it to a stranger's server to find out whether it is safe inverts the entire exercise.
The same applies to hashing text. People paste API responses, tokens and internal identifiers into hash tools while debugging, and a server-side tool receives all of it.
You can verify this rather than trusting it. Open your browser's developer tools, switch to the Network tab, and drop in a file — no request carries it, regardless of size. Or disconnect from the internet after the page loads and hash something anyway. It works, because everything needed is already running on your machine.
Frequently asked questions
Why does it show all five algorithms instead of letting me pick one?
Because the most common reason to hash something is comparing it against a checksum someone published, and that checksum often does not say which algorithm produced it. Computing all five means you can paste what you were given and look for the match rather than guessing. The compare box does exactly that and tells you which algorithm matched.
Is my file uploaded to check its hash?
No. The file is read into your browser's memory and hashed on your own device. Nothing is transmitted. This is important for the main use case: verifying a download you do not yet trust. Uploading an unverified file to a third-party server in order to check whether it is safe would rather defeat the purpose.
Which algorithm should I use?
SHA-256 for anything new. It is the current standard, widely supported, and has no known practical weaknesses. Use MD5 or SHA-1 only to match a checksum someone else published in that format, never for anything you are designing. SHA-512 is stronger still and is a reasonable choice, though on 32-bit hardware it can be slower than SHA-256 for no practical gain.
Why are MD5 and SHA-1 marked as broken?
Both have practical collision attacks — it is possible to construct two different inputs that produce the same hash. MD5 collisions can be generated in seconds on ordinary hardware, and SHA-1's first public collision was demonstrated in 2017. That means neither can be trusted where an adversary might deliberately craft a matching file, which rules out signatures and certificates. They remain adequate for detecting accidental corruption, which is what a download checksum is really for.
Can I use these to hash passwords?
No, and this is the most consequential misuse of hashing there is. Every algorithm here is designed to be fast, which is exactly wrong for passwords — an attacker with a stolen database can test billions of guesses per second. Password storage needs a deliberately slow, salted algorithm such as bcrypt, scrypt or Argon2. Using SHA-256 for passwords is a well-known and serious mistake, not a shortcut.
Why is MD5 available if Web Crypto does not support it?
The browser's Web Crypto API deliberately omits MD5, on the reasonable grounds that it is broken. But published checksums are still frequently MD5, so it is implemented separately here to make those verifiable. It is verified against the test vectors in RFC 1321, the specification that defines the algorithm.
The hash of my downloaded file does not match. What now?
Do not run it. A mismatch means the file differs from the one that was published — most often an incomplete or corrupted download, occasionally something worse. Download it again, ideally from the official source over HTTPS, and check again. If it still does not match, the checksum may be for a different version, or the file may have been tampered with. Check you are comparing against the right release.
Does the same input always produce the same hash?
Always, on any machine, in any language, forever. That determinism is the entire point. It also means hashing is not encryption — there is no key and no way to reverse it, but identical inputs are trivially identifiable. Hashing a short, predictable value like an email address does not anonymise it, because anyone can hash the same guesses and compare.