How to Redact a PDF Without Leaving the Data Behind
Someone asks for a copy of a case file, an incident report, or a supplier contract. Most of it can go out. A handful of names, an address, a bank account number, and a signature cannot. So you open the PDF, draw black rectangles over those parts, save, and send.
That is the moment where most disclosure accidents happen. Knowing how to redact a PDF properly means understanding that a PDF is not a picture of a page. It is a container with several layers, and a black rectangle only changes one of them.
Why a black box is not a redaction
When you draw a filled shape in a PDF editor, you add a new drawing object to the page's content stream. It renders on top of whatever was already there. The characters underneath do not move and are not deleted. They sit in the same text layer they always occupied.
Anyone who opens that file can select through the box and copy the text. A text-extraction script pulls it out in a second. Convert the page to plain text and the "hidden" name appears in the output. The visual result looked convincing on screen, which is exactly why the mistake keeps recurring.
The same logic applies to a few adjacent habits. Changing text colour to white leaves the characters intact. Cropping a page usually hides content rather than discarding it, because the original page geometry is retained. Placing an opaque image over a region covers the pixels but not the data.
A genuine redaction does two things: it removes the underlying content from the file, and it replaces the visible region with something that carries no information. If only the second happens, you have produced a document that looks redacted and is not.
The layers that survive a visual edit
Even when the page content is handled correctly, a PDF carries information outside the visible page.
Document properties. Author, title, subject, keywords, and the producing application. The author field frequently contains a real person's name or a network username.
Attachments. PDFs can embed other files. A spreadsheet attached to a report travels with the report and is not visible on any page.
Form fields. Filled AcroForm values are stored separately from the rendered appearance. Flattening changes how they display; it does not always clear the stored value.
Comments and annotations. Review notes, sticky comments, and highlights are their own objects with their own text and author names.
Bookmarks and the outline tree. Section titles often paraphrase content that has since been redacted from the body.
Incremental save history. PDFs support incremental updates, where a new revision is appended to the end of the file and earlier states remain in the bytes. A file that has been edited and saved repeatedly can contain a readable earlier version of the page you just redacted.
Scanned pages with an OCR layer. A scan looks like an image, but many scans carry an invisible text layer produced by OCR so the document is searchable. Painting over the image does nothing to that text layer.
A redaction workflow that only inspects what is drawn on the page will miss all of these.
Working out what actually needs to come out
Before you touch the file, decide what the released version has to protect against. That is a narrower question than "remove anything sensitive", and it has a body of guidance behind it.
The ICO's anonymisation guidance frames identifiability as a spectrum rather than a binary. Information is not simply identifying or not identifying; it sits somewhere on a range depending on what else is available and who is looking. The guidance sets out key indicators of identifiability and describes an assessment approach that considers who else might be able to identify people from the data, not only what you yourself could do with it.
Central to that assessment is what the ICO calls the motivated intruder test — a way of asking whether a reasonably competent person, with no specialist skill but a real interest in re-identifying someone, could combine the released data with other available information and succeed. The guidance also asks organisations to revisit identifiability risk assessments over time, since the external information available to an intruder changes.
The guidance draws a firm line between anonymisation and pseudonymisation. Pseudonymised data, it explains, is still personal data, because the means of linking it back to an individual exist somewhere. That distinction matters for document work. Replacing every occurrence of a name with "Individual A" throughout a bundle is pseudonymisation, not redaction, and the rest of the document may still make Individual A obvious.
A practical consequence: single direct identifiers are rarely the whole problem. A redacted witness statement that leaves in a job title, a town, and a date can narrow the field to one person. Look at the residual document as a whole.
US-side considerations for documents that hold customer records
If the file contains information about US customers or employees, a different framework applies to how the document is handled once it exists.
The FTC's privacy and security business guidance covers data security across the lifecycle, including secure disposal of sensitive personal information kept in files or on a network. Its guidance also notes that where a company makes privacy promises, expressly or by implication, the FTC Act requires the company to live up to those claims. A privacy policy that describes how documents are handled becomes a statement the business is held to.
The same page points to sector-specific rules that shape document work: the Fair Credit Reporting Act on using, reporting and disposing of consumer report information; the Gramm-Leach-Bliley Act on safeguarding data at financial institutions; and the Health Breach Notification Rule for certain health data breaches. Which of these bear on a given document set is a question for counsel, but they explain why the disposal of intermediate files often gets as much scrutiny as the released version.
A workable sequence
The order below is a practical one rather than a legal requirement.
- Work from a copy. Keep the original intact and unedited, in case you need to reconstruct what was removed.
- Determine whether the page is text or image. Text-layer PDFs and scanned PDFs need different handling. A scan may or may not carry an OCR layer; assume it does until you have checked.
- Mark every region. Names, addresses, account numbers, dates of birth, reference numbers, signatures, and any faces or documents visible in embedded photographs.
- Consider the residual document. Read what is left as an outsider would. Ask whether the combination of remaining details narrows to an individual.
- Apply the removal, then verify by extraction. Do not verify by eye. Run text extraction over the output and search for the strings you removed. If they appear, the removal did not take.
- Check the non-page layers. Document properties, attachments, annotations, bookmarks, form values.
- Handle intermediate files deliberately. Marked-up drafts and working copies contain the unredacted content.
Step 5 is the one people skip. It is also the one that catches the black-box failure, the surviving OCR layer, and the incremental-save remnant, all in a single pass.
Where Scanon fits
Scanon.ai redacts personal information in documents. You can upload a file and work through it in the redaction workspace, or call the REST API, which covers images, video, and documents, if redaction runs inside an existing pipeline rather than as a manual step.
For documents that contain photographs — an incident report with scene images, a claims file with vehicle shots — Scanon.ai detects and redacts faces, license plates, and tattoos in images and video, and strips EXIF metadata from images it processes.
When a redacted document is handed to a third party, that party often has no way to tell which file version they hold. Scanon.ai can issue a redaction certificate that allows a processed document to be verified later at scanon.ai/verify. That is useful in disclosure chains where the same bundle passes through several hands; the legal workflows page covers discovery and filing scenarios in more detail.
Document handling specifics, including supported formats and how output files are produced, are in the documentation.
What to take away
The core of PDF redaction is a gap between what a document displays and what it contains. Close that gap in two directions: remove the content rather than covering it, and check the layers that never appear on screen. Then verify the output with a tool that reads the file rather than looks at it.
The judgement about what to remove is separate from the mechanics of removing it. The ICO's material on identifiability and the motivated intruder test is the place to start on that question, and the FTC's business guidance sets out the US-side framework for handling the files themselves.
Frequently asked questions
Is drawing a black rectangle over text the same as redacting it?
No. A drawn shape is a separate object placed on top of the page. The characters underneath usually remain in the file's text layer and can be selected, copied or extracted with a text-extraction tool. Redaction means the underlying content is removed, not covered.
Does a redacted PDF still count as personal data?
That depends on whether anyone can still identify a person from what remains. The ICO's anonymisation guidance describes identifiability as a spectrum rather than a yes-or-no state, and sets out a motivated intruder test for assessing whether re-identification is reasonably likely. Whether a particular file clears that bar is a judgement for the organisation releasing it.
What is the difference between redaction and pseudonymisation?
The ICO's guidance treats them as distinct. Pseudonymised data is still personal data, because the link back to an individual exists somewhere and can be reversed. Redaction removes content from the document itself, with no key retained inside the file.
What else in a PDF can carry personal information besides the visible page?
Document properties such as author and title, embedded file attachments, bookmarks, form field values, comments and annotations, and revision or change history. Any of these can survive a visual edit to the page.