See what a PDF carries besides its pages

A PDF is a container, not a picture. Alongside the pages it can carry a reviewer’s name on a comment, an attached spreadsheet, form fields holding values that nothing on screen displays, an earlier draft of itself, a page whose margins were cropped rather than trimmed, and a script the document asks your reader’s software to run. None of that appears when you open the file and look at it, which is exactly why it survives being sent.

This reads the file and lists what is in it: text that is in the document and not visible on the page, the document information fields, the separate XMP metadata packet that survives clearing them on many tools, comments and notes with the names and dates attached, embedded files, filled form fields, form fields flagged hidden that still hold values, stored JavaScript, actions that ask a reader to open something else, outbound links, earlier revisions of the document, and pages that were cropped rather than trimmed.

Everything reported is quoted rather than counted. If a comment carries a name, the report shows the name and the sentence; if a hidden field holds a case number, it shows the case number. A count you have to take on trust is not useful when the decision is whether a document is safe to send.

Everything checked and not found is listed too. That is the half most tools skip, and it is the half a person actually needs, because a report that only lists problems cannot be distinguished from a report whose checks never ran. When it says there are no attachments and no earlier revisions, it is telling you that it looked.

The first of those is the failed redaction everyone has read about: a black rectangle drawn over a name, saved, and sent, with the name still sitting in the file underneath it. The obvious way to look for it is to model the page, working out which shapes are opaque and which of them were painted after which words. That is a great deal of PDF semantics to get right and every part of it is a way to be confidently wrong about somebody’s document.

So the question is asked the other way round. The renderer already knows how to draw the page properly, including transparency, clipping and drawing order. Each page is drawn, and any run of text the file lists whose place on the page turns out to be a flat patch of one colour is reported, with the words quoted. Whatever hid it — a rectangle, an image, a clipping path, or white ink on white paper — the file says the words are there and the page does not show them. A highlight is not caught by this, because the text on top of it is perfectly visible, and a scanned page with an invisible OCR layer is not either, because the picture underneath that text is a photograph of glyphs and is not flat at all.

Finding it is not fixing it. Covering text does not remove it, and neither does this tool: Redact PDF cuts the characters out of the content stream and then reads the finished file back to prove they are gone.

One thing it cannot see is text pushed outside the visible area of a page, and the reason is worth stating because a version of this tool did claim to. The renderer returns nothing outside the page’s view box, so on a fixture with a line placed well off the sheet, and on a second with a line above a crop box, it reported the file clear both times. A check that cannot see the thing it looks for is worse than no check, because its silence reads as a clean bill of health. It was removed. The crop finding stays, and it tells you a page was trimmed rather than cut, which is the same warning without the false confidence.

It does not judge anything either: a link to your own website and a link to somewhere you have never heard of look the same to a reader of file structure, so both are shown and the judgement is yours.

The revision check is the one most likely to be wrong elsewhere, so it is deliberately conservative. A file saved incrementally keeps its earlier body and leaves a pointer back to the previous cross-reference table, and that pair of marks is what is required before anything is claimed. A linearised document, which is what most large publishers ship for fast web viewing, carries a second end-of-file marker and the same pointer by design and has no earlier version behind it. Counting that as a recoverable draft would frighten people about entirely ordinary files, so it is identified and discounted, and the report says which case it found.

The whole inspection runs in this tab, on a document that never leaves the device. That matters more here than on a conversion tool: the reason to inspect a file is usually that you are not yet sure it is safe to hand to anyone.