How to Unredact a PDF, and How to Prevent It

Nearly every recovered redaction you have read about came back the same way, and it is not clever. Someone drew a black rectangle over a name in a PDF viewer and saved the file. A rectangle is a drawing. It sits on top of the page like a sticker. The characters underneath it were never touched, and selecting the page and pasting it into a text editor brings them straight back out.

So can you unredact a PDF. It depends entirely on what was done to it, and there are only two answers. If the redaction was a shape drawn over live text, then yes, and trivially, because the value is still in the file. If the text objects themselves were deleted, then no. Not with a better tool, not with a forensic one, not by anyone. The characters are not there to recover. Everything else here follows from which of the two you are holding, and what redacted means in a particular document is exactly that question.

Telling them apart takes fifteen seconds. Open the PDF, select the whole page, copy, and paste into a plain text editor. If a value you believed was removed appears in what you pasted, it was covered rather than redacted and it was never removed at all. If it does not appear, you have ruled out the obvious failure, which is not the same as proof the value is gone.

That failure has embarrassed law firms, government departments and newspapers, repeatedly, for two decades. It keeps happening because the operation looks exactly like what you wanted. The value disappears from view, the file saves, the page looks right when you reopen it. Every signal a careful person would check says the job is done, and the only thing that would tell you otherwise is a step most people do not know to take.

The rectangle is the famous case, and it is not the only one. Setting text to white is the same trick with a different attribute. A highlight annotation is a separate object drawn over live text. Cropping a page hides content without removing it, because a crop is a change to the visible box rather than to what the box contains. In every one of these the value survives, because none of them are deletions.

Then there is everything that is not the page at all. A PDF carries document metadata, and an author or title field routinely holds a name nobody meant to publish. Files that have been through an editor can carry incremental save history. A great many PDFs embed a thumbnail image of the first page, generated before anyone redacted anything. And any scanned page or pasted screenshot is a picture rather than text, so a text based search of that file will report it perfectly clean while the value sits there in pixels for anyone with eyes.

Two things are true about removing one, and they point in opposite directions. A real redaction cannot be removed, by you or by anybody else, because removing it is not a hard problem but an absent one. A fake one comes off in seconds: select the text under the rectangle, or open the file in an editor that lists annotations and delete the black box, which was only ever an object sitting in a layer. That is the whole of it. It is barely a technique, and that is precisely why a covered value is worthless as protection.

Which makes the point of this section a plain one. Remove the redaction and check my own redaction are the same test run for different reasons. The person opening a published filing to see what is underneath and the person checking a production before it goes out do the identical fifteen seconds of work, and only one of them can still fix what it turns up. That is the argument for running it on your own file first.

The copy and paste test is the first step and the cheapest, and it catches the crude failure that most of the news stories were. It will not catch the rest. Metadata does not appear in a page selection. An embedded thumbnail is not text. A value split across two positioning operations in the content stream may not come out cleanly through a viewer's own copy function even though it is plainly present in the bytes. Passing the test tells you that you have not made the obvious mistake. It does not tell you the value is gone.

That gap is why Omit ships a verifier, and why it is free, with or without a licence. In the Redact app it is the Verify tab, headed Verify a redaction. You choose the file, type the values that were supposed to be removed, one per line, and it reports whether any of them can still be recovered and whereabouts in the file each one turned up. The values you type stay on the machine, they are not saved anywhere, and the file is read rather than modified. Deciding what to give it is the same question as deciding what counts as personal information in the document. There is also an omit verify command, which lives in the separate command line package rather than inside the Windows installer, and which exits non-zero when anything survives or when part of the file could not be examined.

For a PDF the check runs four separate passes over the file. It re-extracts the text the way a reader would, walks the filter-decoded streams, tokenizes the content stream operators, and walks every string object in the document. Those are four different encodings a value can survive in, and each one was measured to be the sole catcher of at least one real case. Text encoded as raw glyph indices in a font that carries no character map is beyond any byte level check, and the code states that limit rather than implying it is covered.

It works on a file any tool produced, including ours, and that is deliberate. The situation it is built for is somebody handing you a production and telling you it is clean. You do not have to take that on faith and you do not have to own the tool that made it. Word, Excel and PowerPoint files are checked as packages, every readable part of them, with run boundaries closed up first, because Word splits a name across two runs routinely and a plain substring search would call that absent. Plain text files are searched directly. The app is a free download and the verifier is not one of the things the trial gates.

The limit, stated plainly, is that a byte search cannot answer a question about pixels. An image with no text layer is reported as unexamined rather than clean, and so is a file too large to read within the verifier's 64 MB ceiling. A picture sitting inside a Word document is not read either, because the check reads the readable parts of the package and an image is not one of them. Whenever something could not be examined the result is not presented as a pass, because a check that could not run is not a pass. Knowing which files fall in that category is most of the value.

What an actual redaction does is different in kind from covering. Omit removes the text objects themselves from the PDF rather than painting over them. Then, before the file is written, it checks the output for whether the redacted value can still be recovered from what remains, and if it can, the page is escalated to rasterize and flatten, which destroys the text layer outright. That verification step is the part almost nothing else does. Removing text is not hard. Confirming you removed it is the difference between a redaction and a hope.

If you have already published a document and just discovered it was covered rather than redacted, the honest sequence is short. Assume the value is out, because a published file cannot be recalled and someone may already hold a copy. Replace the file with a properly redacted version so the exposure stops growing. Then treat it as a disclosure and follow whatever obligation actually applies to you, which for a court filing, a health record or a personal data breach is a rule with a clock on it rather than a matter of judgement. Quietly swapping the file and saying nothing is the option that turns a mistake into something worse.