Verifying a SHA-256 checksum, step by step
Sixty-four characters that tell you whether the file you have is exactly the file someone meant to send. Checking them takes one command.
The answer in one paragraph
To verify a file checksum, compute its SHA-256 hash and compare it with the published one. On Windows run certutil -hashfile followed by the file name and SHA256; on macOS run shasum -a 256 and the file name; on Linux run sha256sum and the file name. If the two 64-character strings match exactly, the file is identical to the original.
That is the whole procedure. The rest of this page is about why it works, when it is worth doing, and the mistakes that make people distrust a perfectly good result.
SHA-256 in plain language
A hash function reads every byte of a file and produces a fixed-length summary. SHA-256 produces 256 bits, written as 64 hexadecimal characters. Three properties make it useful.
- It is deterministic. The same bytes always produce the same hash, on any computer, with any tool.
- It is sensitive. Changing a single bit anywhere in the file changes the hash completely, not slightly. There is no such thing as a nearly matching hash.
- It is one-way and collision-resistant. You cannot work backwards from a hash to the file, and nobody has ever found two different inputs that share a SHA-256 hash. That is what lets a short string stand in for a whole document.
When it is worth doing
Any time the exact bytes matter and the file has passed through hands you do not control.
Software downloads are the classic case: a project publishes the hash beside the installer, and a match tells you the copy from a mirror is the genuine article and was not truncated in transit. Contracts are another. If you hash the final PDF when you send it and include the hash in your covering email, either party can later show which version was agreed. Evidence handling works the same way: recording a hash when a file is collected lets anyone confirm later that what is presented is what was collected.
The value always comes from the hash having been recorded somewhere trustworthy. A hash sent in the same email as the file proves the transfer was clean; it does not protect against someone who could change both.
On the command line
Every major operating system ships a hashing tool. Open a terminal in the folder holding the file and run the line for your system, replacing contract.pdf with your file name.
- Windows (Command Prompt or PowerShell): certutil -hashfile contract.pdf SHA256
- Windows (PowerShell only): Get-FileHash contract.pdf, which uses SHA-256 by default
- macOS: shasum -a 256 contract.pdf
- Linux: sha256sum contract.pdf
- Checking a list: if you were given a checksum file in the standard format, sha256sum -c checksums.sha256 on Linux, or shasum -a 256 -c on macOS, checks every file named in it and prints OK or FAILED for each.
In the browser
If a terminal is not to hand, or you are hashing on a locked-down work laptop, browsers have SHA-256 built in through the WebCrypto interface. World of PDF's PDF Hash tool uses it directly: drop in one or more PDFs and you get a SHA-256 digest for each, with SHA-1 and SHA-512 available for matching an existing checksum made with those. It can also download a checksum file in the standard sha256sum format, so a recipient with a terminal can verify with one command.
Because a hash is computed over bytes, the tool never opens the document, which means encrypted and damaged PDFs hash exactly like any other file. The file is not uploaded; you can confirm that by switching your network off before you hash.
A browser hash and a command-line hash of the same file are the same number. If they differ, the files differ.
Why two copies of one PDF can disagree
This is the result that makes people think the tool is broken. Two PDFs that look identical page for page can have entirely different hashes, because a PDF records far more than its pages: a modification date, the name of the program that saved it, an internal document ID, and the order objects were written in. Open a file and press save, and those change.
So a mismatch means the bytes differ, not necessarily the content. PDF Hash's Compare mode answers the follow-up question: alongside the byte hash, it derives a second digest from each file's page text and dimensions, and tells you when files differ in bytes but match in page content. That second digest does not cover images, so where pictures are the point, trust the byte hash.
Also distinct from a hash is a fingerprint in the leak-tracing sense. The Fingerprint PDF tool deliberately makes each recipient's copy slightly different, with a faint code on each page and in the metadata, so a leaked copy can be traced. Every fingerprinted copy therefore has its own hash. One tool answers whether a file is unchanged; the other answers whose copy it was.
Frequently asked questions
How do I check the SHA-256 of a file on Windows?
Open Command Prompt in the file's folder and run certutil -hashfile followed by the file name and SHA256. In PowerShell, Get-FileHash and the file name does the same.
Are uppercase and lowercase checksums different?
No. Hexadecimal is case-insensitive, so ABC123 and abc123 are the same value. Compare the characters, not the case.
Is MD5 or SHA-1 good enough for verifying a file?
For spotting accidental corruption, they still work. For proving a file has not been deliberately altered, use SHA-256: collisions have been demonstrated for both MD5 and SHA-1.
Can I verify a checksum without installing anything?
Yes. Windows, macOS and Linux all include a hashing command, and browsers include SHA-256, so a browser-based tool that hashes locally needs no install and no upload.
What does it mean if the checksum does not match?
The file is not byte-identical to the one the published hash was made from. Download it again; if it still fails, treat the file as wrong until the source confirms otherwise.