Does Redacting a PDF Change Its File Hash?

Nearly every redaction question is a question about the inside of the document: what the black rectangle removed, whether the text underneath survived, whether a figure can be reconstructed from the ones around it. This page is about the outside. It is about the file as a sequence of bytes, and about the single short string that identifies that sequence and no other.

That sounds abstract until the moment it is not. A production protocol asks for a hash value for every document you deliver. A records office logs what it released, and the log has a digest column. Someone sends back the file you gave them three months ago and asks you to confirm it is the one you gave them. You upload the redacted copy to a portal, download it again, and want to know whether what is on the portal is what left your laptop. All four of those are the same question — is this the same file? — and none of them can be answered by looking at the pages.

So they are answered with a hash, and the first thing anybody discovers is that redaction changes it. The second thing, which surprises almost everyone, is that redacting the same document the same way twice also changes it.

What a hash is, briefly

A cryptographic hash function takes a file of any size and produces a fixed-length value — for SHA-256, sixty-four hexadecimal characters. The same bytes always produce the same value. Change one byte and the output is not slightly different, it is entirely different, with no recoverable relationship to the old one. There is no key and no reverse operation; it is a fingerprint, not encryption.

What makes it useful for documents is that comparing two of those strings is as good as comparing the two files byte for byte, and the strings are short enough to put in an email, a log, or a spreadsheet cell. You can also publish a hash without publishing the document, which is why it works as a reference in a production index.

Every desktop operating system can compute one without extra software:

• Linux: sha256sum file.pdf
• macOS: shasum -a 256 file.pdf, or openssl dgst -sha256 file.pdf
• Windows, Command Prompt: certutil -hashfile file.pdf SHA256 — Microsoft documents the syntax as certutil [options] -hashfile InFile [HashAlgorithm], with SHA256 among the supported algorithms
• Windows, PowerShell: Get-FileHash file.pdf. SHA-256 is the default in current PowerShell versions, but the cmdlet takes an -Algorithm parameter and it costs nothing to be explicit: Get-FileHash file.pdf -Algorithm SHA256

Yes, and the change is total

Any edit at all would change a file's hash. But a burn-in redaction of the kind this tool performs does not edit the file — it replaces it. The export creates a brand-new PDF document and writes each page into it as a freshly rendered image. None of the original's page objects, fonts, text streams, annotations or metadata are copied across. What you download is not the original with rectangles added on top; it is a different document that happens to look like the original with rectangles added on top.

That is the whole point, and it is why the text under a box cannot be lifted back out of the exported file. It also means the output's hash has no relationship to the input's: not a shared prefix, not a near-match, nothing. Hash functions are built so that related inputs give unrelated outputs, so there is no sense in which one digest is "close" to another.

The consequence that catches people out is the one that runs backwards. You cannot use hashes to establish that a redacted file and an unredacted file are two versions of the same document, because a hash comparison has exactly two outcomes: identical, or not identical. Proving that two files are different versions of the same thing is a job for your own records — filenames, a log entry, a case reference — not for cryptography.

The surprise: two identical runs, two different hashes

Redact a file, download it, then load the same original, draw the same boxes in the same places, and download again. The two files will not match. Press Download twice in the same session without touching anything and they still will not match.

The reason is a timestamp. A PDF can carry a document information dictionary, and the library that assembles the export writes /CreationDate and /ModDate entries into it automatically, both set to the moment the file was built, in the form D:20261009124841Z. Two exports a second apart differ in exactly those characters — and a one-character difference is a completely different hash. Running the pinned library build that this site loads and comparing two otherwise identical exports made a second apart confirms it: two unrelated SHA-256 values, with every differing byte sitting inside the compressed object stream that carries those dates.

Timestamps are not the only source of variation. Each page is rasterised and embedded as a JPEG produced by your own browser's image encoder. Encoders are not standardised at the byte level and they change between browser versions, so the same document redacted the same way on a different machine will not produce byte-identical pages either, timestamps aside.

None of this is a defect. It just means a hash identifies an artefact and not a procedure. The practical rule follows directly: hash the file you actually delivered, and keep that exact file. You cannot throw it away, repeat the work later, and expect the recorded value to come back.

A workflow for recording what you sent

1. Finish everything that touches the bytes first. Redact, then merge, stamp, compress, sign or convert — then hash. Every one of those steps produces a new file with a new digest, so a hash computed in the middle of the pipeline describes a file nobody will ever see.
2. Hash the delivered copy, not a sibling. If the file you attach is the one in your Downloads folder, hash that one. Two files with the same name in different folders are the classic way to end up certifying a digest for the wrong document.
3. Record the whole value with its context. Filename, algorithm, all sixty-four characters, the date and time, and who produced it. A truncated prefix is fine for eyeballing and useless as a record.
4. Hash the original too, if you are keeping it. The unredacted file is the thing your redaction was derived from, and a digest for it lets you show later that the source you worked from had not been altered in the meantime.
5. Re-hash after any hop that might re-process the file. Some portals and document systems re-save, flatten or OCR what they receive. If the copy on the far side has a different digest, that is usually evidence of re-processing rather than of tampering — but you can only tell the difference if you recorded the value before the hop.
6. Keep the record outside the document. This is forced rather than merely advisable: writing a file's hash into the file changes the file, which changes the hash. No document can contain its own correct digest. Put it in the log, the index or the covering note.

What a hash proves, and what it does not

It proves one thing precisely: that two files are byte-for-byte identical, or that they are not. Within its scope it is close to unarguable, which is why it is worth the thirty seconds.

Everything else people hope it proves, it does not. It does not prove who made the file; anyone can compute a hash of any file, so a digest on its own authenticates nothing about authorship. That is the job of a digital signature. It does not prove when the file existed — the date in your record is your own assertion, not something the hash attests to, which is what trusted timestamping services exist to solve. It says nothing about whether your redaction was adequate, whether the covered content was the right content, or whether the document is accurate. And it does not tell you what the recipient opened, only what you hashed.

Common mistakes and misconceptions

Using a hash as a redaction. Replacing a sensitive value with its hash looks clever and is often reversible. Hashing is deterministic and unkeyed, so when the set of possible inputs is small or guessable — a nine-digit number, a date of birth, a phone number, a name drawn from a known list — anyone can hash every candidate and match it against yours in seconds. The GDPR defines pseudonymisation, in Article 4(5), as processing personal data so that it can no longer be attributed to a specific data subject "without the use of additional information" that is kept separately and protected. A digest of a guessable identifier fails that condition, because the additional information required is just the list of plausible values. If the aim is to remove something, remove it.

Using MD5 or SHA-1 for an evidential record. Both are still common in tooling and both are poor choices where the point is to resist deliberate manipulation. RFC 6151 (2011) states that the published attacks against MD5 "show that it is not prudent to use MD5 when collision resistance is required," and that "MD5 is no longer acceptable where collision resistance is required such as digital signatures." SHA-256 costs nothing extra.

Treating a changed hash as proof of tampering. A re-save by a document management system, a portal that regenerates the PDF, or an archival conversion all change the bytes without changing a pixel of what the reader sees. A mismatch means "not the same file," which is a narrower claim than "someone altered this."

Expecting the hash to say anything about the redaction's quality. A digest of a catastrophically bad redaction is just as clean and just as confident as a digest of a good one. Verification of the redaction itself is a separate exercise, done by opening the file and trying to get the content back.

Hashing a draft. If you hash at the point you finish drawing boxes and then re-export because you spotted a missed line, the recorded value belongs to a file you discarded. Hash last, after the version you are sending exists on disk.

Assuming the tool hands you the hash. It does not. The redaction work happens in the page in front of you, and what you get back is a PDF download — there is no digest shown, no manifest, and nothing computed on your behalf. The hash is a one-line command you run yourself, on your own copy, after the download lands.

Related guides

See also, or use the redaction tool above:

• How to write a redaction log for a redacted PDF
• Keeping the redacted and unredacted versions of a PDF straight

Frequently asked questions