PDF Redaction Checker

Almost everyone who checks a redacted document checks it the same way: open the file, try to select the blacked-out area, see whether anything highlights. That test is worth running and it is nowhere near sufficient, because it interrogates exactly one of the five places a PDF stores readable text. The other four are not obscure or exotic. They are the document properties, the comment layer, embedded file attachments, and the values sitting on form fields — all of them standard, all of them readable by any PDF library in a couple of lines of code, and none of them visible on the page you are looking at.

The reason this matters is that the four invisible routes are untouched by the thing most people do to redact. Drawing a black rectangle appends a fill instruction to a page's drawing program. It does not remove the text instruction that came before it, and it has no relationship at all to the title stored in the document properties or to the sticky note somebody left in the margin during review. You can produce a file where the page looks immaculate and the author's name, the internal project code and a whole attached spreadsheet come back out on request.

A copy-paste test checks one of five routes. Passing it tells you about the page, and nothing about the file.

Why searching the raw file proves nothing either

The next instinct is to open the PDF in a text editor and search for the name. This is worse than useless, because it reliably returns nothing on files that are leaking badly. Measured on our own test document: the name that a PDF reader will happily hand you appears zero times in the raw bytes. Page content is compressed with Flate, and inside that compressed stream the text is written as hexadecimal digits rather than letters — <43414e415259> Tj rather than anything you could recognise. Add subset font names and the word you are hunting is three transformations away from a search box. None of those transformations is protection. Every one of them defeats a naive search, which is precisely the combination that produces false confidence.

The failure that is not about rectangles at all

In practice the most common leak is duller than a botched rectangle: the same name appears on more than one page, and only one page was treated. A redaction tool that flattens a page to an image does its job perfectly on that page and leaves every other page exactly as it was. That is correct behaviour and it is not what the person clicking the button assumes. This checker marks each page as text-carrying, image-only or blank precisely so that pattern is visible at a glance — a run of image-only pages followed by a live one is a job that stopped early.

Where this bites in the region

Singapore's PDPC has published enforcement decisions where the disclosure route was a document nobody thought of as a disclosure — an attachment, a properties field, a review comment — rather than the body of the document. The same shape recurs across Malaysian court filings, Hong Kong legal practice and Australian FOI releases: the redaction on the page was competent, and the file carried the answer somewhere else. Anyone in the region who sends documents to a regulator, a court, a client or a counterparty is doing so under a duty that does not distinguish between "on the page" and "in the file". The distinction only exists inside the software.

What this tool does not do

It does not modify your file, it does not remove anything, and it cannot promise a file is safe. It reports what came back through five ordinary routes, and says so in those terms. It reads embedded text, not pictures of text: a scanned page that has never been through OCR carries no text layer to find, which is why a scan of a document can look identical to a properly flattened one in the page strip. And it inspects what standard libraries enumerate — a producer that stores something unusual in a private key may not be listed. If your obligation is legal rather than practical, treat this as a fast way to catch the ordinary mistakes, not as a certificate.