A Black Box Over Text Does Not Redact a PDF

You open the document, draw a black rectangle over the name, save it, and send it. The page looks exactly the way a redacted page should look. That is the trap: the thing you inspected is the only thing that changed.

The recipient presses Ctrl+A, then Ctrl+C, pastes into a text editor, and reads the name.

This has happened in court filings, in government document releases, in company disclosures and in academic papers, repeatedly, for twenty years, and it keeps happening because the failure is invisible at the moment you make it. Nothing warns you. The file looks right.

A PDF holds two separate things

The reason is structural, and once you see it the whole category of mistake makes sense.

A PDF page is a list of instructions: set this font, move to this position, show this string, fill this rectangle with this colour. The text in the document is not a picture of text - it is a text-showing instruction carrying the actual characters, which is what makes a PDF searchable and selectable in the first place.

When you draw a black rectangle, you append one more instruction to that list: fill a rectangle, in black, at these coordinates. That is all. The text-showing instruction is still there, in its original position, with its original characters. You have not removed anything; you have drawn something on top.

Text selection and text extraction do not look at the picture. They read the instructions. So they read straight through your rectangle, because from their point of view the rectangle is off to one side of the question entirely.

Which produces the defining property of this bug: the more carefully you check your work visually, the more confident you become, and visual checking is the one method that cannot detect the problem.

The annotation version is even weaker

There is a variant that is worse, and it is common because it is the easiest thing to reach for: using the highlighter or shape tool in a PDF reader and setting the colour to black.

That does not add an instruction to the page. It adds an annotation - a separate object floating above the page, of the same kind as a sticky note or a comment. Annotations are designed to be edited and removed.

So the recipient does not even need to extract text. They open the file in any editor, click the black box, and press Delete. The page is restored. No tooling, no expertise, no copy-paste trick - just clicking the thing and removing it, exactly as the format intends.

Four places the content survives

Even when someone does properly remove the text, content has more than one hiding place. A thorough job has to account for all of them.

The text objects on the page. The main one, covered above.

Document metadata. Title, author, subject and keywords travel with the file and are frequently populated automatically from things you did not choose. The original filename ends up in there often enough to matter, and original filenames are famously indiscreet - settlement-smith-confidential-v3.docx tells the story before anyone opens page one. Metadata is not affected by anything you do to the page.

Embedded page previews. Some producers store a small rendered thumbnail of each page inside the file. If that thumbnail was generated before your edit, it is a picture of the unredacted page sitting in the same document.

The file's own history. This is the subtle one. The PDF format permits incremental saving: rather than rewriting the file, an editor can append the changes to the end and leave the previous version in place. The reader shows you the newest state, and the earlier state - including the page as it was before you covered anything - is still bytes in the same file.

This is a legitimate feature, built for speed and for signature workflows where earlier revisions must remain provable. It becomes a disclosure when someone redacts by editing and saving in a tool that saves incrementally by default.

The scanned document case

Worth its own section, because the intuition here points the wrong way.

A scan feels safe. The page is a photograph; there is no text layer to leak; covering part of the image should cover it completely.

Except that almost every scanning workflow now runs OCR, precisely so the result is searchable. The recognised words are stored as invisible text positioned behind the image. That is what lets you search a scanned contract, and it is a genuinely good feature.

It also means the document contains a machine-readable transcript of everything on the page, including whatever you have just drawn a rectangle over. Covering the image does not touch it. The words come out with a text extraction like any others, which is the same reason searching for them worked a moment ago.

If you are redacting a scan, the invisible layer has to be dealt with alongside the pixels - and the check at the end of this post is how you find out whether it was.

Check it in ten seconds

The good news is that this entire class of failure is trivially detectable, and you should never ship a redacted document without doing so. Extract the text and search it for what you removed.

pdftotext redacted.pdf - | grep -i -e 'smith' -e '555-0142'

Empty output means the text is gone. Any output at all means the redaction is decoration. That single command catches the rectangle case, the annotation case and the invisible OCR layer, because all three leave the text extractable.

Then check the metadata, which no page edit touches:

pdfinfo redacted.pdf

Look at Title, Author, Subject and Keywords, and consider what the original filename might have been.

If you want to know whether the file kept its earlier revisions, count the end-of-file markers:

grep -c '%%EOF' redacted.pdf

One is clean. Two is normal for files optimised for web viewing. More than that means the document was saved incrementally several times, and earlier states of those pages may still be present - treat it as a signal to re-save the file properly rather than as proof of a leak.

Do these checks on the file you are actually about to send, not on a test file. The one you send is the only one that matters.

The flattening question

The usual advice, once someone learns about all this, is to flatten the document to images - print it to PDF, or export each page as a picture.

It does work on the main problem. Rendering a page to pixels discards the text objects, so there is nothing left to extract and no invisible OCR layer to forget about.

The costs are real, though, and worth naming before you reach for it. You lose selectable and searchable text throughout the whole document, not just in the redacted parts. You lose accessibility, which for a document going to a public body may not be optional. The file usually gets substantially larger. And flattening does nothing about metadata, so it addresses three of the four hiding places and leaves the fourth exactly as it was.

Flattening is the right answer when certainty matters more than usability - a document going to a court, a regulator, or the press. For an internal document that people need to search, removing the content properly and keeping the text layer is the better trade.

What real redaction means

Three properties, and the third is the one usually missing.

First, the marked content is deleted from the file rather than covered: the text objects go, and where the region falls on an image, the pixels themselves are altered. Second, the other hiding places are handled - metadata, previews, and the file's revision history - because a document is not redacted if the name is only gone from the page.

Third, and this is the part worth insisting on: the finished document is read back and checked. Redaction is one of the few operations where a silent partial failure is worse than an error message, because the whole point is that you are about to hand the file to someone. A tool that re-reads its own output and refuses to hand you a file that still contains the content is making a different kind of promise from one that simply tells you it worked.

That is how Redact PDF is built, including the option to flatten when you want the stronger guarantee, and it processes files in memory rather than storing them - which for the category of document that needs redacting is rather the point. If the file also needs its active content removed, Sanitize PDF covers that separately.

But do the extraction check anyway. Not because you should not trust the tool, but because it takes ten seconds and it is the only step that proves something rather than asserting it.

Common questions

Why is the text still there if I saved the file? Because saving preserved both layers. The rectangle was added; nothing was removed.

Is a black highlight safe? No - it is a removable annotation, so a recipient can simply delete it.

Does flattening fix everything? It fixes the text layer. Metadata needs handling separately.

Can I redact a scan by covering the image? Not on its own. Check for an invisible OCR layer with the extraction command above.

What is the one thing to remember? Never judge a redaction by looking at it. Extract the text and search.

Related reading: what a macro-free document can still do, EXIF data in photos, and protecting files before you share them.