File Hash Checker
Compute SHA-1, SHA-256, and SHA-512 checksums of any file.
This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.
Drop in a file and its SHA-1, SHA-256 and SHA-512 checksums — the SHA256 file hash a download page asks you to compare against — are computed on your own machine and listed together, ready to check against the value a publisher gave for a download.
How to use it
- 1Drop a file onto the dashed box, or click it to pick one.
- 2Wait for the three digests to appear; the file name and its size are shown above them.
- 3Paste the checksum you were given into 'Compare with expected checksum' to get Match or No match.
Example
- Input
- A file containing exactly the three bytes abc, with no trailing newline
- Output
- SHA-1: a9993e364706816aba3e25717850c26c9cd0d89d
MD5 is missing on purpose — the browser digest API used here does not implement it. The compare box does not ask which algorithm your checksum came from; it is tested against all three and names the one that matched.
What happens to your data
Hashing is done by the browser's SubtleCrypto digest function over an ArrayBuffer that File.arrayBuffer() read straight from disk, so there is no upload behind this page and no multipart request to intercept. The whole file has to fit in memory — that is what the 'too large to read into memory' error means — and the buffer is released the moment another file is dropped in.
Last updated August 2026
A download page hands you a 4 GB installer and, in smaller type underneath, a line of hex labelled SHA256. Or a build lands on a shared drive and you want to know whether your copy is the one that came out of the pipeline. Both are the same question: are these bytes the bytes I was expecting.
Decide first what you want the answer to prove. A checksum published beside the file it describes tells you the transfer arrived intact — it catches downloads that stopped early, mirrors serving a stale build, and copies damaged crossing a network. It does not tell you the file is genuine, because anyone able to swap the file could edit the string sitting next to it. Authenticity is a separate job, done with a signature checked against a key from another route.
What a hash cannot do surprises people: it describes bytes, not meaning. Re-save a document without changing a word and the digest changes. Convert its line endings and it changes again. Rename the file and it holds, since the name was never part of what was hashed. There is no partial credit either: one flipped bit produces an unrelated digest, so a checksum tells you something is wrong and never how wrong.
The common mistake is comparing by eye — first six characters, last six, done. That is the one check a damaged file can still pass.
How it works
Toolvore reads the whole file into memory and hands it to the digest function built into your browser three times, once each for SHA-1, SHA-256 and SHA-512, printing each result as lowercase hexadecimal. Reading the file whole is the weak point. There is no streaming and no progress bar, so a large disc image shows a Computing line and nothing else until it finishes or fails with a message about being too large to read into memory. One file is handled at a time, and dropping a second replaces the first; each run is tagged internally, so a slow earlier run can never paint its digests under a newer file's name. The comparison box trims and lowercases whatever you paste and tests it against all three digests at once, which is why it can name the algorithm that matched. What it cannot do is explain a failure: a corrupted file and a checksum from an algorithm this page does not compute both come back as No match.
Common use cases
- Checking a Linux ISO against the SHA256 a mirror publishes
- Confirming a large file survived an upload to shared storage
- Working out whether two copies of a backup are the same file
- Verifying an installer downloaded over a connection that dropped
- Checking a file after copying it to an external drive
- Recording a digest of a file before passing it to someone else
Frequently asked questions
What does a matching checksum actually prove?+
That the bytes you hold are the bytes whoever published the string held. That covers the everyday failures: a download that stopped early, a mirror serving a stale build, a copy damaged crossing a network. It does not prove the file is safe, because a checksum printed on the same page as the download can be edited by anyone able to replace the download. For that you want a signature checked against a key obtained through a different channel, which is what a GPG signature does. Read a match as evidence of a clean transfer, not a security verdict.
SHA-1, SHA-256 or SHA-512 — which should I compare?+
Whichever the publisher gave you; the choice was theirs. Where you do get to choose, SHA-256 is the sensible default. SHA-1 still spots accidental damage well, but deliberate collisions against it were demonstrated in 2017, so do not lean on it where someone might want two files to agree. SHA-512 is not meaningfully safer than SHA-256 here; on 64-bit processors it often runs faster, the honest reason to prefer it. The lengths differ visibly — 40 hexadecimal characters for SHA-1, 64 for SHA-256, 128 for SHA-512 — which is the quickest way to identify an unlabelled checksum.
Is an MD5 checksum still worth checking?+
For catching a corrupted download, yes: MD5 spots accidental damage as reliably as it ever did, and plenty of projects still publish one out of habit. Where someone might be working against you, no. Producing two different files that share an MD5 digest has been cheap for around two decades, so a match does not establish that a file is the one its author released. The same is now true of SHA-1, and nothing of the sort is known for the SHA-2 family. Where a project lists both an MD5 and a SHA-256, compare the SHA-256.
How do I check a file's hash without a browser?+
On Windows, PowerShell has Get-FileHash, which uses SHA-256 unless you pass -Algorithm; the older certutil -hashfile still works from cmd. On macOS, shasum -a 256 gives SHA-256 and shasum -a 1 gives SHA-1. On Linux, sha256sum, sha1sum and sha512sum are usually installed already. Those tools have two advantages. Given a checksum file, sha256sum -c does the comparison itself and prints OK, which removes the human step. They also stream the file in chunks rather than loading it whole, so they cope with disc images and videos that a browser tab will not.
Does the file get uploaded anywhere when it is hashed?+
No. The file is read from disk by the browser and passed to a digest function already built into it, so no request carries the contents anywhere: nothing in transit to intercept, no copy left on a server. That matters, because the files people most want to fingerprint are often the ones they least want to hand over — a database export, a signed contract, a disc image under licence. It also means the page keeps working with the network switched off, a fair way to check the claim rather than take it on trust.
Why do two files that look identical have different hashes?+
Because the hash reads bytes, not meaning. Re-saving a document rewrites internal timestamps and often reorders its contents, so the file differs even when the words do not. A text file with Windows CRLF line endings differs from the same text with Unix LF. Zip archives, and formats built on them, record a modification time for every entry, so archiving a folder twice produces two archives that never agree. Images re-exported by an editor carry different metadata. Going the other way, renaming or moving a file changes nothing inside it, so the digest holds.
The checksums do not match — what should I do?+
Assume a bad download first, because that is usually what happened. Delete the file rather than resuming it, since a resumed transfer that went wrong reassembles into something that looks complete, and fetch it again from a different mirror. Then check you are comparing like with like: a page often lists several files and algorithms, and a SHA-256 held up against a SHA-512 will never agree. Check the string you pasted has not collected a line break or a stray space. If a fresh copy from a second source still disagrees, ask the project rather than running the file.
How large a file can a browser hash?+
No fixed limit is written into this page, but the whole file has to sit in memory at once, which puts the practical ceiling somewhere in the low gigabytes — lower on a phone, or a machine under load. Past that you get the error about the file being too large to read, or the tab gives up on its own. Because nothing reports progress during the read, a large file looks like a hang when it is working. For an ISO or a long video, a command-line tool that streams the file is the better instrument.
Used in these workflows
Related tools
Unicode Escape/Unescape
Convert text to \u escape sequences and back.
Base64 Encode/Decode
Encode text to Base64 or decode Base64 back to text.
UUID Generator
Generate one or many random UUID v4 identifiers.
Password Generator
Generate strong, random passwords with custom rules.