A Black Box Over the Text Removed Nothing At All

We built an eight-page PDF with a line on every page that should not leave the building:

SALARY 184250 GBP

Then we produced two more versions. In the first, a filled black rectangle is drawn over that line — the page looks redacted, and if you print it, it is. In the second, the line is removed before the PDF is written.

Then we ran pdftotextover all three and counted how many pages still gave the string back.

file	pages leaking the line	size
original	8 of 8	5,971 B
black rectangle drawn over it	8 of 8	6,179 B
text actually removed	0 of 8	5,753 B

The covered file leaks on every page. Not some pages, not a partial string — every one, in full, from a document that looks redacted on screen and on paper.

Why the rectangle changes nothing

A PDF page is a list of drawing instructions. "Move here, select this font, show these characters" is one instruction; "fill this rectangle with black" is another. Drawing the rectangle appends an instruction to the end of the list. It does not go back and edit the earlier one, because nothing in the format asks it to.

So the page now says: show the salary, then paint a black box. A renderer follows both in order and you see a black box. A text extractor never renders anything — it walks the same list looking only for the show-text instructions, finds the salary exactly where it always was, and returns it.

This is why the covered file is bigger than the original, at 6,179 bytes against 5,971. You added a rectangle. Nothing was taken away. A redaction that makes the file grow is a useful tell: if the words were really gone, the file would be smaller — as the third row shows, at 5,753 bytes.

The ways this gets discovered

Copy and paste. Select the black area with the text cursor, copy, paste into any text box. The words that appear are the ones underneath.

Search. Ctrl-F for a name in a document where every mention was "redacted" will still highlight them, because the search index is built from the same text layer the extractor reads.

Automated extraction. This is the one that turns a mistake into a story: anyone can run a text extractor over a published PDF, and it takes a second per file. Court filings, government releases and corporate disclosures have all leaked this way, repeatedly, for two decades.

What actually removing it looks like

A real redaction has to edit the content stream — find the show-text instruction, take the characters out, and write the page back without them. That is what produced the third row, and it is why that file is the only one where the count is zero.

Two details worth knowing, because they are where partial fixes fail:

Removing the text is not the same as removing the page. Deleting the page solves it, but you usually want the rest of the page.

The visual black box is still needed. Take the words out and the space is blank, which tells a reader something was there without telling them what. Both steps belong to the job: cover it so the page reads as redacted, and remove it so the file is.

Our PDF redactordoes both. If you want to check a document somebody handed you — yours or anyone else's — PDF to textis the same test we ran here: extract the text and read what comes out. It takes longer to open the file than to find out.

Check your own before you send it

The check is not "does it look redacted". It is "does the text come back". Run the extractor, search the output for the thing you covered, and only then send the file.

And while you are there: the same document is probably carrying an author name, a creation date and the path of the folder it was written in, none of which the page shows. PDF metadata sanitizeris the other half of not saying more than you meant to.