BASALT · JOURNAL

How redactions fail, and what each failure has in common

2026-08-06 · redaction failures

Redaction failures do not look like carelessness from the inside. They look like a completed task: the reviewer drew the boxes, the page went black in the right places, the file got sent. The failure is discovered later by someone who selected the text and pasted it into a text editor.

There are only a handful of distinct mechanisms behind almost every published redaction failure, and they share one property. This post walks through the mechanisms, then names the property.

Pattern one: the box is drawn, the text is not removed

A PDF page is a content stream: a sequence of operators that place glyphs, draw paths, and paint images. Text is placed by text-showing operators such as Tj and TJ, which reference glyph codes in a font resource. Drawing a filled black rectangle appends a path and a fill operator to the same stream.

Painting order decides what you see. The rectangle comes after the text, so it covers it. Nothing in that operation touches the text-showing operators. The glyphs are still there, in order, with their positions and their ToUnicode mapping, which is why text extraction and copy-paste return the supposedly redacted words verbatim.

The same failure occurs when the black box is an annotation rather than page content. A square annotation, a highlight with an opaque color, or a redaction annotation that was placed but never applied are all objects layered over the page. Some of them can be deleted in any PDF editor, which restores the original view in one keystroke. This is the mechanism behind the black box myth.

Pattern two: the image was covered, the OCR layer was not

Scanned documents are usually two things stacked: a raster image of the page, and an invisible text layer produced by OCR and drawn in rendering mode 3, meaning "place these glyphs but do not paint them." That invisible layer is what makes a scan searchable.

Cover part of the image with a black rectangle and you have hidden the pixels. The invisible glyph run underneath is untouched, and it contains the same words the scanner read. Text extraction returns them. This one is especially common because the person doing the redaction cannot see the text layer at any point in the process, so there is nothing on screen to remind them it exists. Redacting scanned PDFs has to handle both layers or it handles neither.

Pattern three: the earlier revision is still in the file

PDF supports incremental update. A change can be written by appending new objects and a new cross-reference section to the end of the existing bytes. The previous objects remain physically present; the new cross-reference table just stops pointing at them.

A tool that removes a page, replaces an image, or excises text and then saves incrementally produces a file where the original is recoverable by parsing the earlier revision. No exotic tooling is required. Truncating the file at the previous %%EOF and opening it is often enough.

This is why "save" and "save as" can produce materially different security outcomes from the same editing session, and why any serious redaction has to be written as a single generation with a fresh cross-reference table.

Pattern four: the data is in a field the page never displays

Several PDF structures carry text that is not part of what you look at.

An AcroForm field has a value in /V and a separate appearance stream that draws it. Clearing the visible box without clearing /V leaves the answer in the file. Markup annotations store their body text in /Contents and their author in /T. Tagged PDFs carry a structure tree where an /ActualText entry can hold the intended reading of a region, which stays correct even if the glyphs beneath it were altered. Optional content groups, meaning layers, ship with the file whether their visibility flag is on or off, so a layer named "draft notes" set to hidden is fully present.

Then there is the metadata: the Info dictionary and XMP packets naming the author, the original file path, the machine, and an edit history listing each application that touched the document. A redaction can be technically perfect on the page and still identify the source through xmpMM:History. That side of the problem is covered in removing metadata from a PDF on a Mac.

Pattern five: the visible geometry was changed, not the data

Cropping a page sets /CropBox, which tells a viewer what region to display. The content outside it is still in the content stream and still renders if the crop box is widened or removed.

The same logic applies to images. Placing a smaller version of a photo on the page does not remove the larger XObject if it is still in the page resources. Scaling an image down in an editor sometimes just changes its transformation matrix. And a page "deleted" by removing it from the page tree may still exist as an orphaned object until the file is rewritten. I go through the image cases specifically in redacting images in a PDF.

Pattern six: the box is opaque but its width talks

This one is a partial failure rather than a total one, and it is worth understanding because it survives an otherwise correct redaction.

Most documents are set in proportional fonts with known metrics. If a black bar exactly covers the removed word, the width of the bar is the sum of the advance widths of the glyphs that were there. Combined with the surrounding context, the language, and a candidate list, that width can narrow a name or a number to a small set, sometimes to one. Consistent bar heights and baselines give away line breaks and capitalization too.

The defense is not clever geometry. It is not letting the redaction mark communicate any measurement: use uniform marks that do not track glyph extents, or remove and reflow, depending on what the receiving party requires. If the production format requires the page layout to be preserved, accept that a determined reader learns the length, and consider whether that alone is disclosive.

What all of these have in common

Every one of these failures is the same mistake in a different costume: the visible layer was changed and the data layer was not.

PDF makes that mistake easy on purpose. Drawing is cheap. Appending is cheap. Both are single operations that any renderer supports. Removing content is structurally expensive: you have to parse the content stream, identify the glyph runs that intersect the mark, excise them, re-emit the surviving text with its positioning intact so the page still looks right, decode and re-encode any image that the mark crosses, then rewrite the whole document as one generation so no earlier state survives. Tools that offer redaction without doing that work are offering a drawing feature with a legal-sounding name.

The second thing they share is procedural: nobody re-opened the output. Every failure listed above is detectable in under a minute by a person with the finished file and a text extractor. Extract the text and search for the redacted strings. List and export the images. Dump the objects uncompressed and read them. Check the annotation values, the form field values, the layer names, and the metadata. If a string you removed appears anywhere in that dump, the redaction failed, and you found it before your counterparty did.

A verification step that runs on the artifact you are about to send, rather than on the state of the editor you sent it from, catches all six patterns. How to verify a PDF redaction covers the specific commands.