A redaction is only finished when it has been verified. That sounds cautious, but the history of leaked "redactions" is a history of files sent on trust: a black box that looked solid, a mark that missed a second occurrence, a footer that repeated the supposedly removed name on every page. Verification takes a few minutes, and it is the step that turns a redaction from an intention into a fact.

The rule is simple: verify the exact file you intend to send, not a draft, not a preview, and not an earlier version that looked similar. Redact PDF performs true redaction in your browser, rebuilding marked pages as images so the covered text is removed rather than hidden. Even with true redaction, verification is still the right habit, because the most likely failure is not the tool but the marking — a missed occurrence, a clipped word, a detail left in metadata.

Test one: select and copy

Open the redacted file in a PDF reader and try to select the redacted area with your mouse. On a truly redacted page, rebuilt as an image, there should be no text to select in that region. If you can select words there, something is wrong: either the page was not truly redacted, or you are looking at an unredacted version of the file.

Next, copy whatever you can select around the region and paste it into a plain text editor. Read the paste carefully. It should contain none of the removed details. This test catches the classic black-box failure, where the text survives under a rectangle and appears in full when pasted. It also catches partial failures, where a fragment of a word survived at the edge of a mark and appears in the paste as a clue to the whole.

Do this test on every redacted page, not just the first. A file with ten redacted pages can pass on nine and fail on one, and the one that fails is the one that matters.

Test two: search the whole document

Use the reader's find function to search for each removed item: every name, number, address, and case reference from your redaction list. Search for full terms and for distinctive fragments — a surname alone, the last four digits of an account number, a unique phrase. A thorough search should return no matches for any removed item.

Search matters because it looks at the text layer of the whole file, including places you may not have examined visually: headers, footers, and pages you did not think contained the item. If a search finds a removed name on a page you believed was clean, that page needs marking and redacting too, and the verification must start again on the new file.

Also search for the item in different forms. A name may appear with a middle initial in one place and without it in another; an account number may appear with spaces in one place and without them in another. Your search list should include the variants you found when you planned the redaction, not only the canonical form.

Test three: extract and inspect

If you have a tool that extracts text from a PDF, run it on the redacted file and read the extracted text, or search within it. Extraction looks at the file's content stream directly, bypassing the visual layer entirely, so it catches cases where a reader's selection behaves oddly but the text still survives underneath. If the extracted text contains any removed detail, the redaction has failed, however clean the pages look.

Finally, inspect the file's metadata and any comments or annotations. A document's title, author field, or comment thread can carry the very details removed from the pages. This step is easy to forget because metadata is invisible in normal reading, and it is worth doing explicitly: open the document properties, check the fields, and remove or correct anything sensitive before sending.

Worked example: a fictional contract excerpt, verified

Imagine a fictional contract excerpt, invented for this example, prepared by a fictional solicitor named Daniel, at daniel@example.org. The excerpt will be shared with a third party, with two client names, a bank account number, and an internal reference removed. Daniel redacts a copy with Redact PDF, then verifies the exact file he intends to send.

First, he selects and copies each redacted region; nothing selectable appears, and the pasted text contains no client names or numbers. Second, he searches the whole document for each client surname, for the account number's distinctive digits, and for the internal reference; all searches return no matches. Third, he extracts the text and searches the extraction; again, nothing. Fourth, he checks the document properties and finds the internal reference still sitting in the title field — a detail that was never on a visible page. He corrects the title, saves a fresh copy, and repeats the three tests on that copy, which now passes all of them.

Only then does he send the file. The extra minutes bought something the redaction alone could not: certainty about the file that actually left his hands, including a metadata leak that no page-level check would have caught. If Daniel also needs to check what changed between the original and the released version, Compare PDF can diff them, and if the excerpt needs joining to a covering note, Merge PDF joins files — with redaction and verification done last, after all other edits.

Honest limitations

Verification can prove that a specific file, tested in specific ways, does not contain the items you searched for. It cannot prove that the file contains no identifying information at all, because you can only search for items you thought to list. Indirect identifiers — a unique combination of dates, roles, and places that identifies someone without naming them — will not appear in a search for a name, and catching them requires human judgement about what the remaining document reveals together.

Verification also cannot control what happens after sending. A recipient can share the file onwards, and a redacted document's remaining content may still be sensitive in a context you did not anticipate. Verification is a necessary step, not a complete guarantee, and for high-stakes disclosures it should sit alongside a second human review and, where appropriate, professional advice.

For the security context in which shared documents travel, see the HTTP security headers guide.

FAQs

How do I check that a redaction really worked?

Select and copy the redacted area, search the whole document for the removed words, and extract the text and search that too. If any test recovers the content, the redaction failed. Test the exact file you intend to send.

Why check metadata as well as pages?

Because document properties, comments, and annotations can carry details that were removed from the visible pages. A name removed from every page can still sit in a title field, and a recipient who checks properties will find it.

What if my search finds a removed name on another page?

Mark and redact that occurrence too, then verify the new file from the start. A redaction is not finished until a full-document search returns no matches for any removed item.

Is verification enough on its own for a legal disclosure?

It is necessary but not sufficient. Verification proves the tested file does not contain the items you searched for; it does not judge whether your redaction plan was complete, or whether remaining details identify someone indirectly. A second human review is wise for high-stakes disclosures.

human review pending client designation