Hash Generator
MD5, SHA-1 and SHA-2 for text or a file, with a checksum check built in.
- MD5128 bitsnot secureBroken since 2004. Fine for spotting a corrupted download, useless against anyone deliberate.
- SHA-1160 bitsnot secureCollisions demonstrated in 2017 and cheap since 2020. Still seen in Git and old certificates.
- SHA-256256 bitsThe default choice. What almost every checksum you meet will be.
- SHA-384384 bitsSHA-512 truncated. Used where a 256-bit digest is thought too short.
- SHA-512512 bitsFaster than SHA-256 on 64-bit hardware, despite the larger output.
Comparing two sixty-four character strings by eye is the task people are worst at, so paste the published value and let it do the reading. The algorithm is worked out from the length of what you paste.
Nothing is uploaded. A file dropped here is read by the tab and hashed in the tab, which is the only sensible arrangement for something you are checking because you do not fully trust it.
MD5 and SHA-1 are marked as not secure because they are. MD5 has been broken since Wang and Yu published a collision in 2004, and SHA-1 since the SHAttered attack of 2017. Both remain perfectly good at spotting a download that got corrupted in transit, which is an accident rather than an adversary, and both are useless against anybody deliberately constructing a file to match. They are here because vendors still publish MD5 checksums and Git still uses SHA-1, not because they are a reasonable choice for anything new.
The MD5 is computed here rather than by the browser, because the Web Crypto standard deliberately refuses to implement it. That is the right decision for a cryptographic API and an unhelpful one when a vendor has published an MD5 and you need to check it.
How the Hash Generator works
Hashes for text you type or a file you drop, in MD5, SHA-1, SHA-256, SHA-384 and SHA-512 at once. Paste the checksum a vendor published and it tells you whether your copy matches, working out which algorithm you pasted from its length. Nothing is uploaded: a file dropped here is read and hashed in the tab, which is the only sensible arrangement for something you are checking because you do not fully trust it.
Also known as: md5 generator · sha256 hash online · checksum calculator · file hash verifier · sha1 generator
What a checksum actually tells you
A hash is a fixed-length fingerprint of some data. Change one byte anywhere and the fingerprint changes completely, which is what makes it useful for answering one narrow question: is this file byte-for-byte identical to the one somebody else had?
That question has two very different versions. The first is whether the file survived the journey: did the download complete, did the disk hold it, did the transfer corrupt a block. Every hash here answers that perfectly well, including the broken ones, because random corruption has no way of steering toward a matching digest.
The second version is whether the file is the one that was published, in a world where somebody might want you to have a different one. That needs a hash nobody can construct a collision for, and it needs the checksum to have reached you through a channel the attacker does not also control. A checksum printed on the same page as the download, over the same connection, protects against a corrupted transfer and against nothing else, which is worth knowing before you take it as proof of anything.
MD5 and SHA-1: broken, and still everywhere
MD5 has been broken since 2004, when Wang and Yu demonstrated a collision, and chosen-prefix collisions, where an attacker constructs two meaningfully different files with the same digest, have been within reach of ordinary hardware for over a decade. The Flame malware used exactly that in 2012 to forge a Microsoft code-signing certificate.
SHA-1 held out longer and fell in 2017 to the SHAttered attack, which produced two PDFs with the same digest. By 2020 chosen-prefix collisions against it cost a few tens of thousands of dollars of compute, which is well inside the budget of anyone who would bother.
Both are still everywhere. Git identifies every object by its SHA-1. Plenty of vendors still publish MD5 checksums beside their downloads. Older certificate chains, archive formats and database columns are full of both. Refusing to compute them does not remove them from the world, so they are here, labelled, with the distinction that matters spelled out: fine for detecting an accident, useless against an adversary.
Why the browser will not do MD5
The Web Crypto API implements SHA-1, SHA-256, SHA-384 and SHA-512 and pointedly does not implement MD5. That is deliberate. The working group's position was that a cryptographic API should not hand out a primitive it knows to be broken, because the presence of a function is itself an implicit recommendation.
It is a defensible decision that leaves a practical gap: when a vendor has published an MD5 and you need to check your download against it, you need MD5, and the reason is not that you think it is secure. So this page implements it directly, from RFC 1321.
Writing a hash by hand is exactly the kind of code that can be subtly wrong and look fine, so it is checked against two independent references: the seven test vectors the RFC publishes in its appendix, which exist for precisely this purpose, and OpenSSL by way of Node, at every input length from zero to two hundred bytes and across four hundred random inputs. The lengths around 55, 56 and 57 bytes matter most, because that is where MD5 padding decides whether the length field fits in the current block or forces another, and it is the classic place for an implementation to be right about everything else and wrong there.
Comparing two long strings is a job for a machine
The standard way to verify a download is to run a hash, then look at the result and the published value side by side and decide whether they match. Comparing two unstructured sixty-four character hex strings by eye is close to the worst task you can give a person. Most people check the first four characters and the last four and call it done, which an attacker who can grind out a partial match would find very convenient.
So paste the published value here and let it do the comparison. It ignores case, because checksums are quoted in upper and lower, and strips whitespace, because they arrive wrapped across lines out of emails and README files.
It also works out which algorithm the checksum came from, by its length: 32 hex characters is MD5, 40 is SHA-1, 64 is SHA-256, 96 is SHA-384 and 128 is SHA-512. The five do not collide. This saves the specific mistake of comparing a published SHA-256 against a computed MD5, seeing no resemblance, and concluding the download is corrupt.
Frequently asked questions
Is my file uploaded?
No. It is read by the page and hashed there. You can watch the network tab, or turn the network off and confirm it still works. That matters here more than usual, since the reason to check a hash is that you are not certain about the file.
Is MD5 safe to use?
Not for anything an adversary can influence. It has been broken since Wang and Yu published a collision in 2004, and constructing two files with the same MD5 has been cheap for over a decade. It is still perfectly good at spotting a download corrupted in transit, because that is an accident rather than an attack. Treat a matching MD5 as evidence the transfer worked, not as evidence the file is genuine.
Why does the browser not do MD5 itself?
Because the Web Crypto specification deliberately leaves it out, on the grounds that a cryptographic API should not offer a broken primitive. That is the right call and an unhelpful one when a vendor has published an MD5 and you need to check it, so this page computes MD5 itself, from RFC 1321. It is verified against the seven test vectors the RFC publishes and against OpenSSL at every input length from zero to two hundred bytes.
What about SHA-1?
Also broken, since the SHAttered collision of 2017, and cheap to attack since 2020. You will still meet it constantly because Git uses it for object identifiers and older certificates and signatures depend on it. Same rule as MD5: fine for detecting accidental change, useless against anyone deliberate.
Which should I use for something new?
SHA-256 unless you have a specific reason otherwise. It is what almost every published checksum uses. SHA-512 is actually faster on 64-bit hardware despite the longer output, so it is a reasonable choice where you control both ends.
How does the checksum check work?
Paste what the download page published and it is compared against the matching digest, ignoring case and whitespace, since checksums are quoted both ways and arrive wrapped out of emails. The algorithm is inferred from the length, which stops people comparing a SHA-256 against an MD5 and concluding their file is corrupt.
Related calculators
Base64 Encoder and Decoder
Handles emoji and every other script, which most converters cannot.
OpenUUID Generator
Version 4 UUIDs, correct to RFC 9562, as many as you need.
OpenPassword Generator
Cryptographically random, generated in your browser, never sent anywhere.
Open