← All posts

A Black Box Is Not Redaction

· 6 min read

There is a particular kind of data breach that happens in slow motion. Someone opens a sensitive document, draws a black rectangle over a name, a Social Security number, an address. They save it as a PDF. They send it to the other side, or file it with a court, or publish it. It looks redacted. Everyone involved believes it is redacted.

Then a journalist opens the file, selects the page, presses Ctrl-C, and pastes it into a text editor. Every "redacted" word is right there.

This has happened to law firms, government agencies, and public companies. It keeps happening, because the tools people reach for — the annotation and markup features in ordinary PDF readers — are drawing tools. They add a shape to the page. They do not remove anything underneath it.

That distinction is the entire reason this product exists.

Why the black box fails

A PDF is not a picture of a document. It is a set of instructions: place this text, in this font, at these coordinates. When you draw a filled rectangle over a line of text, you add one more instruction to the end of the list: also draw a black box here.

The original instruction is untouched. The words are still in the file, still in reading order, still selectable, still indexed by search engines. You have put a sticker over the text, not erased it. Anyone can peel it off with:

  • Copy and paste — select the page and paste it somewhere else
  • pdftotext — one command, prints every word in the file
  • Any PDF editor — delete the rectangle you just drew

A test you can run in ten seconds (and the one we'd rather you ran on us too — try the free tool): open a document you believe is redacted, select all, copy, and paste it into a plain text editor. If the sensitive text appears, it was never redacted.

What we do instead

On pages with real text, we delete the text. We locate every match in the document's content stream and remove those instructions from the file entirely, then draw the black box over the now-empty space. The box is cosmetic — a marker showing where something was removed. The security comes from the deletion. Copy and paste the output and you get nothing, because there is nothing left to copy.

On scanned pages, we destroy pixels. (More on that in how to redact a scanned document.) A scan has no text to delete; the information is an image. So we read the page with OCR to find where the sensitive values physically sit, paint those regions solid black in the image data, and rebuild the page from the modified image. The original image object is discarded, not hidden behind something. There is no layer to peel back, because the pixels that formed those characters no longer exist.

You can read exactly how we handle your file on the security page. We strip the metadata too. Author names, titles, creation software, and XMP records travel inside PDFs and routinely carry more identifying information than the visible page. We clear them on the way out.

The failure nobody talks about: mixed pages

Here is a bug we found in our own pipeline, and the reason we now test the way we do.

Most documents are not cleanly one thing or the other. A billing statement has selectable text and a scanned remittance slip. A contract has a text body and a photographed ID stapled to the back. An invoice has text and a stamp.

A tool that classifies each page as either "text" or "scan" will route these pages down the text path — because they do have text — redact the text layer perfectly, and never look at the image at all. The output looks flawless. The text-layer PII is genuinely gone. And the Social Security number sitting inside the embedded image is still there, perfectly legible, in a file the user has been told is clean.

We caught this by extracting the images back out of our own "redacted" output and looking at them. The number was right there. We now OCR embedded images on every page, whatever else is on it, and replace those images in place — so the text layer and page layout survive, and the pixels still get destroyed.

Teams filing court documents hit this constantly — see redaction for legal teams. This is the class of bug that makes redaction tools dangerous rather than merely imperfect: it fails silently. Nothing errors. The user sees tidy black bars and reasonable-looking output, and ships it.

OCR accuracy is a security property, not a feature

For scanned documents, the only thing that knows where the sensitive data sits is the OCR engine. If OCR cannot read a number, the tool cannot redact it — and the failure is invisible, because a miss produces no error, just an unmarked page.

We tested this with a real passport photographed at an angle on a desk: rotated, slightly skewed, small text over a patterned security background. Ordinary document scans, in other words.

The common open-source OCR engine read zero words from that page. Not a few wrong ones — nothing at all. A pipeline built on it would have returned that passport untouched while reporting success.

A commercial-grade OCR service read 117 words from the same image, correctly handling the rotation and the low-contrast background, and the name and date of birth were removed cleanly. We verified the result by running OCR over the output again and confirming that nothing sensitive could be read back.

That gap is why we pay per page for OCR on scanned documents instead of using the free option. On a clean digital PDF you would never notice the difference. On a photo of a passport, it is the difference between a redacted document and a disclosed one.

How we know it works

Claims about redaction are easy to make and easy to check, so we check.

Our test suite does not ask whether a black box was drawn. It takes the finished output and attacks it: extracting the raw text, pulling embedded images back out of the file and reading them, searching the uncompressed file for the values that were supposed to be gone. A test only passes when the sensitive content cannot be recovered by any of those routes.

Every change to the redaction path has to survive that before it ships.

What we don't claim

A security tool that oversells itself is worse than one that is honest about its edges, so here are ours.

Handwriting is not detected. OCR reads print, not cursive. A handwritten signature or a note scrawled in a margin will not be found automatically. If you need those gone, mark them yourself.

OCR recall on badly degraded scans is not perfect. A heavily compressed fax, a third-generation photocopy, or a very low-resolution phone photo can defeat any OCR engine. Better OCR moves this a long way, but nothing moves it to 100%.

Automatic detection is a starting point, not a guarantee. We find well-formed patterns — Social Security numbers, card numbers with valid checksums, emails, phone numbers — and any names or terms you specify. We do not claim to understand your document well enough to know what else in it is sensitive.

For anything high-stakes, look at the output before you send it. That advice holds for every redaction tool, including ours; the difference is that when we do remove something, it is actually gone.

The short version

Most tools cover. We delete. On text, the words are removed from the file. On scans, the pixels are destroyed and the original image is thrown away. Embedded images get checked even when the page has perfectly good text. Metadata is stripped. And your document isn't stored — it is processed and discarded within seconds.

Try the copy-paste test on whatever you're using now. It takes ten seconds, and what you find may be unwelcome.

Try it on a document you've already redacted

Select the page, copy it, and paste it into a text editor. If the text is still there, it was never removed.