Does this file match the checksum you were given?
Pick a file, paste the digest the publisher listed, and find out. The file is read and hashed inside your browser — nothing is uploaded, and no checksum is fetched from anywhere on your behalf.
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
What a match actually proves
That the file on your disk is byte-for-byte identical to whatever produced the checksum you pasted. Nothing more, and the distinction matters.
It does not tell you the file is safe, or that it came from who you think, or that it has not been tampered with — unless the checksum itself came from somewhere an attacker could not reach. A digest printed on the same page as the download link, delivered over the same connection, only protects against accidental corruption: anyone able to alter the file could alter the number beside it just as easily.
A checksum earns its keep when it arrives by a different route. Signed with the project's key, quoted in a release announcement you already trust, carried in a distribution's package metadata, or written down by you before the file moved.
What is normalised before comparing
Whitespace and letter case, and nothing else. Digests get copied out of terminals, emails and web pages, and arrive with line breaks in the middle, a trailing newline, or in capitals — none of which changes the value.
Two things are deliberately not forgiven. A digest of the wrong length for the selected algorithm is reported as malformed rather than padded or truncated to fit, and anything containing a character that is not a hex digit is refused outright. Both are far more likely to mean the paste went wrong than that the file is bad, and quietly "fixing" either would turn a copy-paste error into a scary red mismatch.
Many publishers list checksums as digest␣␣filename, so a trailing filename is stripped if what is left is a valid digest.
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.
If it does not match
The overwhelmingly likely explanation is a truncated or resumed download, or the wrong file — not an attack. Download it again, ideally from a different mirror, and check the size against what the publisher lists before anything else.
The next most likely explanation is that the digest and the file are not meant to go together: a checksum for a different version, a different architecture, or the installer rather than the archive. Publishers usually list several.
Only when the file downloads identically twice from different places, and still does not match a checksum you got from a route the download did not travel, is there anything to be concerned about.
Reading a checksum file
Projects often publish a SHA256SUMS file with one line per release: the digest, two spaces, then the filename. Paste the line for your file and the filename is stripped automatically. If the checksum file has a detached signature beside it — usually .asc or .sig — that signature is the part actually worth verifying, because it is what ties the digests to the project's key rather than to whoever served the page.
Related
The hash calculator produces a digest to publish or record. The file comparator checks two files against each other without a published digest at all.
Questions people actually ask
What does a match prove?
That your file is byte-for-byte identical to whatever produced the digest you pasted. It does not prove the file is safe or that it came from who you think — unless the checksum itself came from somewhere an attacker could not reach. One printed beside the download, over the same connection, only rules out accidental corruption.
It does not match. Have I been attacked?
Almost certainly not. In order of likelihood: an incomplete or resumed download, a checksum belonging to a different version or architecture, or a paste that lost a character. Download again from a different mirror and check the file size first. Only a file that downloads identically twice and still fails a checksum obtained by an independent route is worth worrying about.
Does case or spacing matter?
No. Whitespace and letter case are normalised, and a trailing filename is stripped, because SHA256SUMS lines are written as digest, two spaces, filename. What is not normalised is a wrong length or a non-hex character — those are reported as malformed rather than trimmed to fit, since both usually mean the paste went wrong and quietly fixing them would turn a copy-paste slip into an alarming mismatch.
Why is SHA-1 still offered here?
Because checking against an old published digest is a real need, and refusing to do the arithmetic does not improve the old digest. It is labelled obsolete and carries a warning: practical collisions have existed since 2017, so a match tells you the file is the one that digest was taken from, and nothing about whether a different file could have been constructed to match it.
Can it fetch the checksum from a URL for me?
No, deliberately. Fetching a checksum on your behalf would mean this page making a request to a third party, which breaks the one promise the tool makes; and a digest fetched over the same kind of connection as the file adds very little anyway. Paste it in.
Is the file uploaded?
No. It is read into your browser's memory and hashed by the browser's own Web Crypto implementation. Nothing leaves the page — you can watch the network tab while you use it.