BASALT · JOURNAL
PDF redaction under the GDPR: what erasure actually requires
A GDPR erasure request that lands on a document set eventually becomes a PDF problem. Someone has to remove personal data from files that will still be disclosed, archived, or produced, and then be able to say what was removed and show it. The gap most organizations discover late is that the file format retains copies of data in places a page view never shows.
This article is written from the file format side. It describes what personal data survives in a PDF after a naive redaction, and what a defensible removal process looks like. It is not legal advice, and the sufficiency of any particular measure is a determination for your counsel or data protection officer.
The obligations that touch a file
Article 17 establishes a right to erasure of personal data in defined circumstances, subject to the exemptions the article itself sets out. Article 5 sets the principles that apply throughout, including data minimization, which limits processing to what is adequate, relevant, and necessary, and storage limitation, which constrains how long identifiable data is kept. Article 32 requires security of processing appropriate to the risk.
None of these articles say anything about content streams. They set outcomes. The technical question is whether a given file, after your process runs, still contains the personal data you undertook to remove, because if it does, the outcome was not achieved regardless of how the page looks.
That is the whole of the engineering problem: a PDF can display a redacted page and still contain the data.
Where personal data hides in a PDF
A PDF is a container of objects. The page you see is produced by a content stream, but text and identifiers can exist in several structures that are independent of it.
Content stream operands. Text is drawn by text-showing operators such as Tj and TJ, whose operands are strings of character codes. Painting a rectangle over the resulting glyphs appends a fill operator. The operands remain. Copy and paste, text extraction, and search all read the operands.
The /ActualText and /Alt entries. Tagged PDFs carry accessibility text for marked content. A name can be present in /ActualText even where the visible glyphs have been altered, and screen readers and extractors will read it.
Document information and XMP. The document information dictionary holds /Author, /Title, /Creator, and /Producer. The XMP packet is an XML block that frequently carries the original filename, the authoring account, document identifiers, and in some workflows a history of prior document versions. These are common leak sources, and removing them is covered in removing PDF metadata on a Mac.
Annotations. Comments, sticky notes, and markup annotations store their text in the annotation object, not the page content. A comment quoting the passage it annotates preserves that passage after the passage is removed.
Form fields. AcroForm field values live in the form dictionary. A field's rendered appearance stream and its stored value are separate. Flattening the appearance does not clear the value.
Embedded files. Attachments are complete files carried inside the PDF. A spreadsheet of data subjects attached to a report is not touched by any page-level operation.
Optional content groups. Layers can be present but not visible. A layer switched off still ships its content.
Incremental update chains. PDF supports saving by appending: a new set of objects and a new cross-reference section are added to the end and the previous bytes are left in place. A viewer resolves to the newest version. A parser walking the file can recover the earlier one. A redaction saved incrementally can leave the unredacted object sitting in the same file.
Stale thumbnails and cached appearances. Page thumbnail images and previously generated appearance streams can depict the pre-redaction page.
Hidden data in PDFs goes through each of these with examples.
Redaction versus deletion versus anonymization
These are three different operations and mixing them up causes real problems in a records program.
Deleting the document removes everything, including the parts you may be required to retain. Redaction removes specified content and keeps the rest of the record intact, which is usually what a production or an archive needs. Anonymization aims at a state where a person is no longer identifiable, which is a higher and more contextual standard than removing the obvious identifiers, because indirect identifiers can re-identify in combination.
Removing a name from a document that also states a job title, a site location, and a start date may not produce anonymized data. Whether the residual set still identifies someone is a judgment about context and available auxiliary information, not something a PDF tool can decide. What a tool can do is remove exactly what you specify and prove that it did.
Building a defensible process
Regulators and courts tend to be interested in whether you had a process and followed it, not in your vendor's marketing. A few structural points that survive scrutiny:
Redact before, not after, distribution. Once a file has been sent, the copies are outside your process.
Rewrite, never append. The output should be a full serialization of the document, with the object graph rebuilt from the redacted state. If the output file is the input plus a small delta, you got an incremental save and the prior state may still be in the bytes.
Verify against the written file. A tool's internal claim of success is a claim about its own data structures. The meaningful check re-opens the saved bytes with an independent parser, extracts all text, and reads every annotation, form field, attachment, and metadata packet, then searches that output for the strings that were supposed to be gone. See verifying a PDF redaction.
Record what you did. A log of which regions were removed, on which pages, under which basis, on which date, and a hash of the resulting file lets you answer questions months later without reopening the document. Hashes are useful because they let you demonstrate that the file you are discussing is the file you produced.
Watch the processor question. Uploading documents to a web-based redaction service is a transfer of personal data to a third party, which brings processor obligations and, depending on the service, international transfer questions. Doing the work locally on a machine you control avoids introducing a processor for this step at all. The risk in cloud PDF tools covers the practical implications.
Do not forget scans. A scanned page that has been through OCR carries an invisible text layer aligned to the image. Removing the pixels under a mark without removing that text layer leaves the personal data fully extractable. See redacting scanned documents.
Frequently asked questions
Does the GDPR require deleting data from a PDF?
Article 17 creates a right to erasure of personal data in defined circumstances, subject to the exemptions the article sets out, and where it applies it concerns the personal data rather than any particular file format. In practice that often means either deleting a document or removing the personal data from it while retaining the rest of the record. Which route is required depends on your legal basis and retention obligations, which is a determination for your counsel.
Is a black box over text enough to satisfy a GDPR erasure request?
No. A drawn black rectangle is an added fill operation that changes what is displayed while leaving the original text-showing operators and their character codes in the file. The personal data remains extractable by anyone who parses the document rather than viewing it, so the data has not been erased in any meaningful sense.
Is redaction the same as anonymization under the GDPR?
No. Redaction removes specified content, while anonymization is a state in which a person can no longer be identified, directly or indirectly, taking account of all means reasonably likely to be used. Removing a name can leave behind indirect identifiers such as role, location, and dates that still identify someone in combination. Whether a redacted document is anonymized is a contextual assessment, not a property of the tool.
What personal data survives in a PDF after redaction?
Data commonly survives in document metadata and the XMP packet, annotation and comment values, form field values, embedded file attachments, accessibility text such as /ActualText, optional content layers that are hidden rather than absent, stale page thumbnails, and earlier document states retained through incremental save chains. Each of these stores text independently of the visible page, so a page-level edit does not touch them.
Can I use an online PDF redaction tool for GDPR work?
You can, but uploading the document transfers personal data to a third party, which introduces processor obligations and, depending on where the service runs, international transfer considerations. That transfer occurs before any redaction is applied, so it is a processing event in its own right. Performing the work locally avoids adding a processor for this step.
How do I prove a PDF redaction actually removed the data?
Re-open the saved file with a parser that had no part in writing it, extract all text, and search that output for the terms you removed, then repeat the search across metadata, annotations, form fields, and attachments. Recording a cryptographic hash of the output lets you later show that a given file is the one you produced. Proof comes from inspecting the written bytes, not from the tool reporting success.
Does redacting a scanned PDF remove the personal data?
Only if the invisible OCR text layer is removed along with the image pixels. Scanners and PDF tools routinely add a searchable text layer positioned under the page image, and erasing the visible pixels leaves that layer fully extractable. A correct process destroys both the pixels within the marked region and the underlying text.
Do I need to keep a record of what was redacted?
Keeping a record is generally good practice for demonstrating accountability, since it lets you show what was removed, when, on which pages, and on what basis, without reopening the document. A file hash recorded alongside that log lets you tie the record to a specific output file. Your retention obligations and your regulator's expectations determine what the record needs to contain.
Doing it in Basalt
Basalt removes text by excising it from the content stream glyph by glyph and re-emitting the surviving text in place, destroys and re-encodes image pixels under a mark including the OCR text layer beneath it, and strips metadata, XMP, attachments, hidden layers, and stale thumbnails, writing the result as one generation rather than an incremental append. Before any file is saved, a built-in verifier re-opens the written bytes with an independent parser and proves the removal, and if it cannot prove it, nothing is written. Each job can produce a signed certificate of redaction, verifiable later with shasum and openssl without Basalt installed, and output is byte-reproducible so the same inputs give the same file. The engine runs as a separate process with no network entitlement, enforced by macOS at the code-signature level, so documents never leave the Mac and no third party processes them. Basalt removes content and proves the removal, and whether that satisfies a given obligation remains your determination: you can try it at basaltformac.com.
Redaction that proves itself
Basalt destroys the content you mark, then re-opens the file it wrote and proves the content is gone before it saves anything. Your documents never leave your Mac.