Hidden data · in depth
Hidden dataTwelve categories, and every path to them.
Editing the text on a page does nothing to the parts of a PDF a reader never sees. Painting over the page does nothing to them either. This is the closed list of what gets removed, and the mechanical reason a checklist is not enough to remove it.
The list
Twelve categories, each one something the engine can find, remove, and then prove gone. The default policy is all of them.
- 01Document infoTitle, author, subject, keywords, producer
- 02XMP metadataCatalog and page metadata streams — often a staler second copy of the above
- 03JavaScriptThe name tree, and every JavaScript action reachable from anywhere else
- 04Open actionWhat the document does the moment it opens
- 05Additional actionsActions triggered by page and document events
- 06Hidden layersOptional content, and the groups it configures
- 07Embedded filesThe name tree, and every file spec reaching a stream
- 08Form fieldsThe form dictionary and the widget annotations holding the values
- 09Annotation actionsWhat annotations do when clicked or focused
- 10AnnotationsEvery page's annotation list
- 11BookmarksThe outline — whose titles routinely name people
- 12Page thumbnailsA rendered picture of each page before redaction
Why a checklist is not enough
The writer drops what it cannot reach. That is the whole mechanism, and it has one consequence worth stating carefully: a category is only gone when every path to it is cut. Two examples, both of which have their own tests:
- Delete the form dictionary and the widget annotation is still sitting on the page's annotation list — with the field value inside it. The form is “removed”; the answer someone typed is not.
-
Delete the optional-content properties and the layer
group stays alive through the page's own resources, carrying its name
with it. In one test file that name reads
Confidential layer.
The audit walks the object graph rather than checking a list of well-known keys — because a checklist would have called both of those files clean, and both of them still name someone.
The report counts references removed rather than objects, and says so: what survived is the audit's question, and it is answered by looking rather than by subtracting.
All twelve on by default, and the receipt for the written file naming each one it checked.
What you keep is your decision, and it is written down
Anything you switch off is reported as kept rather than as a failure — with what is present, so the receipt stays a description of the file rather than a verdict on your policy. Two limits belong in the same breath:
The verifier does not search inside embedded file streams. An attachment is removed whole or kept whole; a policy that keeps them gets a line saying they were kept and how many are present, never a claim about what is in them.
A kept category is still matched. The text inside it goes through your rules like anything else — so keeping bookmarks does not excuse a bookmark that names the subject.
Why this sits next to the receipt
The scrub is also the reason the receipt needs two channels rather than
one. A file can extract as Owner of record: — the page naming
nobody — while a form field still holds the name, and a file whose page
names nobody at all can carry it in the document info and in a bookmark
title. Removal and verification are the same argument told twice:
how the receipt is made covers the
other half.
Twelve categories, removed by default, and a receipt that names each one it checked in the file it wrote.
See launch details