Hash a file without uploading it
Calculate a SHA-256, SHA-384 or SHA-512 digest of a file or of text, entirely inside your browser. The file is read into memory and hashed there; it is never sent anywhere, and there is no server involved that could receive it.
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
What a hash is for, and what it is not for
A cryptographic hash turns any amount of data into a short fixed-length value, in a way that makes it infeasible to find two different inputs with the same output. Change one bit of a file and the digest changes completely.
That makes it useful for one specific thing: checking that a file you have is byte-for-byte the file somebody else had. Compare the digest you calculate here against one published by whoever produced the file, and if they match, nothing has changed in transit.
It is not encryption. A hash cannot be reversed and it does not protect anything — a file and its digest are equally readable. It also says nothing about whether a file is safe: a matching digest on a malicious file only tells you it is exactly the malicious file the publisher had.
Why very large files fail
The browser's Web Crypto interface has no way to feed a hash function piece by piece — you hand it the whole input and get the digest back. So the entire file has to be in memory at once, and above roughly two gigabytes most browsers will refuse to allocate the buffer.
The usual workaround is a JavaScript implementation of SHA-256 that can be fed in chunks, and there is one thing wrong with that here: it means shipping an implementation of a cryptographic primitive rather than using the one built into your browser, which is the opposite of how everything else on this page is built. For files that large, the operating system tools are better suited anyway — shasum -a 256 on macOS and Linux, certutil -hashfile on Windows.
What this tool does not claim
No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.
Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.
Which algorithm to use
SHA-256 unless you have a reason not to. It is what almost every project publishes, it is what package managers and operating systems use, and there is no known attack against it.
SHA-384 and SHA-512 produce longer digests from the same family. On 64-bit hardware SHA-512 is often faster than SHA-256 despite doing more work, because it operates on 64-bit words. Use them when what you are comparing against uses them.
SHA-1 and MD5 are not offered for calculating new digests. Both have practical collision attacks — two different files with the same digest can be produced deliberately — so a match no longer establishes what people assume it does. If you need to check against an old published SHA-1, the checksum verifier offers it with that caveat attached.
Checking a download
Hash the file, then compare against the digest the publisher lists. The comparison is the easy part; the part people skip is that the published digest has to come from somewhere you trust. A checksum printed on the same page as the download link, over the same connection, is only useful against corruption in transit — anyone who could alter the file could alter the checksum beside it.
A digest is worth much more when it arrives by a different route: signed by the project's key, published in a release announcement, quoted in a distribution's package metadata, or simply written down by you before the file moved.
Related
The checksum verifier compares against a digest you paste. The file comparator checks two files against each other. Or see everything under Cryptography & Security.
Questions people actually ask
Is my file uploaded?
No. It is read into your browser's memory and hashed there by the browser's own Web Crypto implementation. There is no upload step and no server on our side that could receive it — you can confirm that by opening your browser's network tab while you use the page.
Which algorithm should I pick?
SHA-256 unless what you are comparing against uses something else. It is the default nearly everywhere and has no known weakness. SHA-384 and SHA-512 are longer digests from the same family; on 64-bit machines SHA-512 is often the faster of the two despite doing more work.
Why is MD5 not offered?
Because a matching MD5 no longer means what people think it means. Producing two different files with the same MD5 has been practical since 2004 and can now be done in seconds, so a match does not establish that a file is the one the publisher had. SHA-1 is in the same position since 2017. The checksum verifier still accepts them for checking against an old published value, with the caveat attached.
Does a matching hash mean the file is safe?
No. It means the file is byte-for-byte identical to whatever produced the digest you are comparing against. If that digest came from somewhere untrustworthy — or from the same page as the download, over the same connection — a match proves very little. The value of a checksum comes from where it was published, not from the arithmetic.
What is the size limit?
Whatever your browser will hold in memory, usually somewhere around two gigabytes. Web Crypto has no way to hash a file piece by piece, so the whole thing has to be resident at once. For anything larger, your operating system's own tool is the right answer: shasum -a 256 on macOS and Linux, certutil -hashfile on Windows.
Is the filename sent anywhere?
No. It is displayed to you and used for nothing else. Nothing on this page reports to analytics, and the shared engine behind it refuses to emit any event carrying a filename at all.