BASALT · JOURNAL

PDF redaction not working: the five things that are usually wrong

2026-08-07 · pdf redaction not working

When you find your PDF redaction not working, the cause is almost always one of five specific things, and four of them leave the original words physically present in the file. The fifth leaves them in an earlier revision that is still inside the document you are about to send.

None of them is visible on the rendered page, which is why the problem surfaces after distribution rather than during review. Each has a distinct signature you can check in a terminal.

Five reasons for PDF redaction not working

One: the mark is an annotation, not an edit

The most common failure. Markup tools create an object in the page's /Annots array with a rectangle, a /Square subtype, a color, and an appearance stream: a comment shaped like a rectangle, sitting beside the page content rather than inside it.

Deleting that annotation reveals the page exactly as it was, because the text operators were never touched. That is documented, intended behavior for annotations.

Two: the box was flattened but the glyphs were not removed

Flattening merges the annotation into the content stream so the rectangle can no longer be deleted as an object, and it is often mistaken for a fix. The text-showing operators are untouched: Tj and TJ still hold the original character codes, and extraction walks those operators directly without regard for painting order.

Three: a scan was covered and the OCR layer survived

Scanned pages usually carry an invisible text layer produced by OCR, drawn in text rendering mode 3 and positioned over the picture of the words so the document is searchable. Cover the image with a mark and that layer is still fully extractable, and some tools that do redact the visible image leave it alone because it is not what you clicked on. This is the case handled in redacting a scanned PDF with an OCR layer.

Four: the same string lives somewhere that is not page content

A name can be excised from the visible glyph run and still be present in several places that never appear on the page you are reviewing.

/ActualText and /Alt entries hold plain text equivalents of marked content spans for accessibility. Form field values live in the field dictionary rather than in page content, so covering a widget's appearance leaves the value intact. Annotation /Contents strings, bookmark titles, and embedded attachments each carry their own.

Five: the file was saved as an incremental update

PDF permits appending a new revision to the end of a file, leaving the earlier bytes and an older cross reference table in place, and many applications save this way by default because it is fast and preserves signatures. Save a redaction that way and the pre-redaction page is physically inside the file you distributed, recoverable by walking the update chain back one generation. The page looks redacted and the document contains both versions.

How to tell which one you have

The checks read the file, not the rendering. Install Poppler, qpdf, and exiftool with Homebrew and work on a copy.

Start with extraction, which catches causes one, two, and three.

pdftotext -layout suspect.pdf - | grep -i "smith"

A clean result is not proof, because fonts with a missing or wrong /ToUnicode map can hold the original character codes while producing empty output. Expand the structure and read it directly.

qpdf --qdf --object-streams=disable suspect.pdf expanded.pdf
strings expanded.pdf | grep -i "smith"

In the expanded file, search for /Annots and /Subtype /Square to identify cause one, and for /ActualText, /Contents, and /OCGs to identify cause four. Form field values appear under /V in the dictionaries reachable from /AcroForm.

Count generations for cause five.

strings suspect.pdf | grep -c "%%EOF"

More than one marker means earlier revisions are present. Signing and ordinary editing also append revisions, so this is a prompt to look rather than a verdict.

Then check the carriers never on a page: exiftool -a -u -g1 suspect.pdf for the information dictionary and XMP packet, and pdfdetach -list suspect.pdf for embedded files.

For scans, extract the images and open them, since a page-level mark does nothing to the pixels inside an embedded image object.

pdfimages -all suspect.pdf ./extracted/img

The full sequence is in how to verify a PDF redaction.

Fixing it properly

Go back to the source document, because a repaired copy inherits the update chain, the metadata, and the thumbnails from the failed attempt.

Real redaction is a content stream edit. The text operators are parsed into individual glyph runs with real page positions, accounting for the text matrix, font size, horizontal scaling, character and word spacing, and the kerning adjustments inside a TJ array. Because a TJ array usually holds a whole line, the excision is per glyph, and surviving glyphs are re-emitted in place.

Image pixels under a mark are overwritten and the image re-encoded, so the original DCTDecode stream cannot be extracted whole, and invisible OCR text at the marked coordinates is excised alongside the visible content. /ActualText, form field values, annotation strings, and optional content groups are cleared rather than covered.

The file is then written as a single generation with a fresh cross reference table, and metadata, XMP, attachments, and stale thumbnails are stripped in the same pass. What a PDF still carries after you think you cleaned it has the inventory.

The last requirement is evidence: verify the output with a parser other than the one that wrote it, because a confirmation dialog reports intent rather than outcome.