Back to Knowledge Hub
SecuritySeptember 1, 2026

Why PDF Redaction Fails: The Black Box Problem

Quick Summary

Drawing a black rectangle over sensitive text does not remove it. Here is why redactions leak, how the failures happen, and how to redact properly.

Approx. 6 min read

In January 2019, lawyers for Paul Manafort filed a court document with portions blacked out. Within hours, reporters had read every redacted line. Nobody broke any encryption. They selected the text under the black boxes, copied it, and pasted it somewhere else.

This is not a rare mistake made by careless people. It has happened to government agencies, law firms, intelligence services, and Fortune 500 companies. The reason is that PDF redaction fails in a way that is invisible to the person doing the redacting: the document looks correct on screen, and the failure only surfaces when someone else opens it.

A PDF is not a picture of a page

The root of the problem is a mental model mismatch. Most people picture a PDF the way they picture a photograph — a flat image where covering something with black paint destroys what was underneath.

A PDF is closer to a set of drawing instructions. A text-based PDF contains a content stream that says, in effect: set this font, move to these coordinates, draw the characters "Account No. 4471-2298". When you draw a rectangle on top, you have not edited that instruction. You have added a second instruction that says fill this area with black, and told the renderer to execute it afterwards.

Both instructions are still in the file. The viewer paints the text, then paints a black box over it. Your eyes see a black box. The text extraction layer, which does not care about painting order at all, sees the original string exactly as it always was.

Copy and paste reads the text layer. So does search. So does any script that opens the file programmatically.

The four ways redactions leak

The copy-paste failure is the famous one, but it is not the only route.

Annotation-layer boxes

Most PDF viewers let you draw a filled rectangle as an annotation — a comment-layer object that sits above the page rather than inside it. Annotations can often be deleted outright in another editor, which removes the box and reveals the page beneath it untouched. A reader does not even need to copy text; they can just delete your rectangle.

Vector graphics conversion

Converting a PDF to SVG or opening it in a vector illustration program separates every drawn object onto its own layer. The black rectangle becomes one object; the text becomes another. Hiding one reveals the other. This takes about ten seconds for anyone who has used design software.

Metadata and revision history

Even if the visible page is clean, the sensitive string may survive elsewhere in the file. Document properties, XMP packets, form field values, and the incremental-update history of a document that was edited repeatedly can all carry text that no longer appears on any page. We wrote about what PDFs leak in their metadata separately, because it is a large enough problem on its own.

The OCR text layer under a scan

This one catches people who did everything else right. A scanned document is an image, so painting over it genuinely does destroy the pixels. But if the file was run through OCR at any point, it carries an invisible text layer aligned behind the image. Flattening the picture does nothing to that layer. The words remain searchable underneath.

What proper redaction actually does

Real redaction is a destructive edit, not a cosmetic one. It has to remove the underlying content from the file, not obscure it. That means:

  1. Deleting the text objects themselves from the content stream, not covering them.
  2. Rasterising the affected region, so the area becomes pixels with no recoverable structure.
  3. Stripping the associated metadata — the document info dictionary, XMP, and any form fields holding the same value.
  4. Removing the OCR text layer for that region if one exists.

The signal that a tool is doing this properly is that redaction is irreversible and the file size changes. If your "redaction" is instant, reversible with undo after saving, and leaves the file byte count essentially identical, it is drawing, not redacting.

Our own Redact PDF tool removes the underlying content rather than covering it, which is the entire reason it exists as a separate tool from Edit PDF — the editor draws shapes, and drawing a black shape is exactly the mistake this article is about.

How to verify your own work

Do not trust the preview. Verify. Three checks, in increasing order of thoroughness:

Select-all test. Open the finished file, press Ctrl+A, copy everything, and paste it into a plain text editor. If the redacted string appears in the paste, the redaction failed. This catches the most common failure in about fifteen seconds and should be a reflex.

Search test. Use the viewer's find function to search for the exact string you redacted. Search reads the text layer, so a hit means the text is still present even if you cannot see it.

Extraction test. For genuinely sensitive material, convert the redacted PDF to plain text or images with a separate tool and inspect the output. Converting to JPG and back is a crude but effective flattening step, because a JPG has no text layer to leak — though you lose searchability and accessibility in the process, so it is a last resort rather than a default.

A note on the stakes

The reason this matters more than most document-handling mistakes is that redaction failures are silent and permanent. A file with a broken redaction looks correct to the person who made it, passes internal review because reviewers also just look at it, and is only discovered after it has been distributed — at which point the disclosure cannot be recalled. Every copy that was downloaded still contains the text.

If you are redacting something that would cause real harm if exposed — medical records, financial identifiers, a witness name, an unreleased figure — do the select-all test before the file leaves your machine. It costs fifteen seconds and it is the single highest-value habit in document handling.

P

Piqav

Written by the team that builds Piqav's browser-based document tools. We work on client-side WebAssembly processing, document security, and practical PDF and image workflows - and we write these guides from what we learn building and testing them.