Hash a PDF, or check whether two files match

How to PDF Hash

1. Pick what you need. Generate a hash for one or more PDFs, or switch to Compare to check two files against each other.
2. Add your files. Drop them in. Encrypted and damaged PDFs work here too — a checksum reads bytes and never opens the document.
3. Read the result. You get a SHA-256 digest per file, or a plain verdict on whether the two files match and, if they don't, whether the pages actually changed.
4. Save or share it. Copy a single hash, or download a standard checksum file the recipient can verify with sha256sum -c.

What a checksum actually proves

It proves the bytes are identical. If you hash a contract before emailing it and the recipient hashes what arrived, matching digests mean nothing was altered, truncated or corrupted along the way — not by a flaky transfer and not by anyone in between. Mismatched digests mean something changed, though not what.

The property that makes this work is that the digest is not reversible and not steerable: you cannot look at a hash and reconstruct the file, and you cannot make a meaningful edit that happens to leave the hash unchanged. That is why checksums are published alongside software downloads and why they hold up as evidence that a document is the one you were sent.

Why two PDFs that look identical can have different hashes

Because a PDF records far more than what you see on the page. Open a document in any reader and save it, and the file will usually gain a new modification date and a new producer string, and may have its internal objects written in a different order. Nothing on any page changed, but thousands of bytes did — so the checksum is completely different.

This trips people up constantly, so the Compare mode here answers both questions at once. Alongside the byte comparison it derives a second digest from the pages themselves — their text and their dimensions — and if the files differ while that matches, it says so explicitly. "Different files, identical page content" is usually the answer people were actually looking for.

That second digest deliberately covers text and page geometry, not images. Two files whose wording is identical but whose photographs differ will match on content and differ on bytes, and in that situation the checksum is the signal to trust. The tool says which comparison it is reporting rather than blurring the two together.

Which algorithm to use

SHA-256 unless something specific requires otherwise. It is the default here, it is what most verification workflows expect, and no practical attack against it exists.

SHA-1 is offered only for matching a digest generated by something older. It should not be used to argue that two documents are the same, because constructing two different files with the same SHA-1 is demonstrably achievable — and PDFs were the format chosen to demonstrate it, precisely because a PDF has so many places to hide the padding such an attack needs.

SHA-512 produces a longer digest. It is not meaningfully more secure than SHA-256 for this purpose, and the extra length mostly makes it more annoying to compare by eye, but it is here for workflows that ask for it.

• Verifying a file arrived intact — SHA-256
• Matching an existing checksum from another tool — whichever it used
• Proving two documents are the same — SHA-256, never SHA-1

The one tool here that works on a broken PDF

Every other tool on this site has to parse your document before it can do anything, which means an encrypted file, a truncated download or a PDF a program crashed halfway through writing will fail to open. Hashing has no such requirement: it reads bytes and produces a digest, and it neither knows nor cares whether those bytes form a valid PDF.

That makes this the right first step when a file is behaving strangely. Hash the copy you have and the copy on the server, and you find out immediately whether the problem is a corrupted transfer or a document that was already broken before it was sent.

Frequently asked questions