Black Boxes Don't Redact PDFs — the Text Is Still Right There

A lawyer draws a black box over a name in a PDF, exports it, and files it with the court. The name is still in the file — select the black box and hit copy. This isn’t a rare mistake. It’s the default outcome of the most common way people try to redact a PDF, and it has leaked real, sensitive information in public more than once.

Why the black box doesn’t touch the text

A PDF page isn’t a picture — it’s a small program. The page content stream is a sequence of drawing operators: some paint shapes, some show text, and the PDF spec keeps them completely independent of each other. A filled rectangle looks like this in the raw content stream:

0 0 0 rg              % set fill color: black
100 400 220 18 re     % rectangle: x y width height
f                      % fill it

And the text underneath it, drawn earlier in the same stream, looks like this:

BT
/F1 12 Tf
100 402 Td
(Account Number: 4111 1111 1111 1111) Tj
ET

Nothing links these two blocks. The re/f sequence paints black pixels at a location; the Tj sequence separately places glyphs at a location. Draw the rectangle after the text and it visually covers it when the page renders — but the text-showing operator is untouched, the font’s still embedded, and the string Account Number: 4111 1111 1111 1111 is sitting in the file exactly as it was before you added the box. Select-all, copy-paste, pdftotext, a search index, a screen reader — anything that reads the content stream rather than looking at the rendered pixels — sees straight through it.

The same bug shows up outside Acrobat, too

It’s not just PDF annotation tools. The identical failure happens whenever the redaction step is “cover it visually” instead of “delete it”:

• Word, highlighted black, exported to PDF. Highlighting a run of text black (or drawing a black text-box shape over it) in Word and exporting to PDF keeps the original run in the PDF’s text layer. The export just draws your black shape as one more object in the content stream, on top of text that Word still wrote out normally.
• Markup/annotation tools that add a shape layer. Any tool where “redact” really means “add an annotation object with an opaque fill” has this same gap — the annotation and the underlying content stream are separate objects, and removing the annotation (or just reading past it) recovers the original.

The only thing that actually differs case to case is which format the leftover text is easiest to pull out with — copy-paste, pdftotext, or opening the PDF in a text editor and reading the raw stream.

It has already leaked

• DOJ’s Epstein-files release, December 2025. Under the Epstein Files Transparency Act — signed into law in November 2025 with a 30-day deadline for the Justice Department to make the records public — DOJ began publishing the files around the December 19, 2025 deadline, in batches that continued over the following days (some pages in the release were entirely blacked out rather than partially redacted). Once the batches were out, the same old bug showed up again: at least one of the black-box redactions in the released PDFs had left the underlying text intact, and it took nothing more than highlighting the covered area, copying, and pasting elsewhere to read it. Same mechanism as every case below — a box was drawn as its own layer on top of the page, and the text layer underneath was never touched.
• Paul Manafort’s Mueller-investigation court filing, January 2019. Manafort’s defense team filed a response to prosecutors with several passages covered by black rectangles. A Guardian reporter selected the blacked-out sections, copied them, and pasted them into a new document — revealing that Manafort was accused of sharing 2016 campaign polling data with Konstantin Kilimnik, a business associate with Russian intelligence ties. The underlying cause was the same content-stream separation described above: the boxes were never flattened into the actual page content, so a plain copy-paste walked right past them.
• TSA Screening Standard Operating Procedures manual, December 2009. The TSA posted a redacted version of its internal screening manual — covering things like explosive-detection machine calibration and procedures for law enforcement and diplomats — as a bid solicitation on a federal contracting site. The redactions were black boxes over a PDF with the text layer left in place; copying the boxed sections into another document recovered them in full. The document was pulled down within days, but not before it was mirrored, including by WikiLeaks.

Three different organizations, sixteen years apart, same root cause every time: a shape drawn on top of text is not the same operation as removing the text. The stakes ranged from an internal government manual to a federal criminal case to one of the most closely watched document releases in recent memory — the bug doesn’t care how high-profile the file is.

What actually removes it

Of the three approaches below, only the last two actually hold up, and they trade off against each other:

Approach	What happens to the text	What you get back	Trade-off
Black box / highlight overlay	Untouched — still in the content stream	Visually hidden, fully recoverable	Not redaction. Never use for anything sensitive.
Delete the text-showing operators for the covered region	Removed from the content stream	A page that still has selectable text everywhere else	Requires precisely identifying and stripping every operator touching the region — glyph-level PDF surgery, easy to get subtly wrong (partial glyphs, clipped text runs)
Rasterize the page: render to pixels, composite the box into the raster, embed the flat image as the new page	Gone — there is no text object left, only pixel data	A page image with the covered pixels genuinely destroyed	The whole page loses selectable/searchable text, and the file gets bigger (an embedded image instead of a few bytes of text)

The second row is the “correct” surgical fix and it’s what dedicated redaction software in legal/gov settings does — but it’s a lot of moving parts to get exactly right on arbitrary PDFs from arbitrary sources. The third row is blunter and it’s what browser-based tools can do reliably: once a page is a raster image, there is no text layer to leave behind by accident. That bluntness is a feature, not a corner cut — a smaller, more surgical fix has more edge cases where a stray text fragment survives.

The trade-off is real and worth saying plainly: a rasterized page can’t be selected, searched, or copied anymore — not just the redacted part, the whole page. That loss is the proof the content is actually gone, not a downside to apologize for. If a “redacted” PDF still lets you select text on the page you redacted, that’s a sign the covered text might still be there too.

The second leak channel: metadata

Even a correctly redacted page body doesn’t clear the whole document. PDFs carry a separate metadata dictionary and, often, XMP metadata — title, author, the software that produced the file, sometimes a revision history — that has nothing to do with the page content and isn’t touched by anything that only edits the visible page. A body that’s genuinely redacted can still leave the original author’s name, an internal filename, or a “last modified by” field intact in the document properties. It’s a completely separate check from the redaction itself — worth doing with the PDF Metadata Editor on any document you’re about to send outside your organization, redacted or not.

How to verify your own redaction

Don’t trust the visual — check the extractable text directly, on the actual output file:

1. Open the redacted PDF, select all (Ctrl/Cmd+A), copy, and paste into a plain text editor. If the thing you redacted shows up in the pasted text, it’s still in the file.
2. If you have poppler-utils installed, it’s faster from the command line:

pdftotext redacted.pdf - | grep "the thing you redacted"

No match means no text-layer leak. It doesn’t check the metadata dictionary or XMP separately — do that with a metadata viewer, per above.

3. If a page you redacted still lets you drag-select individual words, that’s the same signal as step 1 — a rasterized page won’t let you select anything at all.

How PDF Redact handles this

PDF Redact rasterizes exactly the pages you draw boxes on — pdf.js renders the page to a canvas, the boxed pixels get overwritten with solid black, and that flat image becomes the new page, embedded and re-saved. Pages you never touch are copied through untouched as vector, so a 40-page contract with one redacted paragraph doesn’t turn the other 39 pages into images. It runs entirely in your browser; the file never gets uploaded anywhere.

The honest trade-off from the table above applies here exactly: any page with a box on it loses its selectable text, because that’s what “gone” looks like. Don’t take our word for either half of that — run the verification steps above on the output before you send it anywhere. For a screenshot or photo instead of a PDF, the equivalent tool is Blur / Pixelate / Redact Image, and if pixelation or blur is your instinct for hiding something instead of a solid fill, it’s worth reading why that specific approach is reversible too before you rely on it. For plain text — logs, tickets, prompts — the PII Scrubber automates the structured identifiers, though it can’t find names or addresses at all, which is a limit worth understanding before you trust a “0 findings” result.

A few related jobs, if a redacted PDF is part of something bigger: Unlock PDF if the file is password- or permission-restricted before you can even open it to redact; PDF to Images if you want every page as a flat image, not just the redacted ones; EXIF Remover if the leak you’re worried about is a photo, not a document.