Most "redacted" PDFs and Word documents are not redacted at all — they are visually covered. The sensitive text still exists in the document's underlying content, and a simple copy-paste or text-extraction pass can pull it out from behind the mark. This has happened in real, publicly reported cases. It keeps happening because covering text is easy and most tools never verify that the text is actually gone.
Redaction that isn't redaction
A PDF page is not a photograph. Underneath whatever you see rendered on screen, most PDFs store an actual text layer — a stream of encoded character data that a viewer, a search index, or a copy-paste operation can read directly. When someone "redacts" a document by drawing a black rectangle, applying a highlighter color, or dropping an opaque image over a paragraph, they are adding a new object on top of the page. They are not touching the text stream underneath it.
The result looks redacted. It is not. Select the area with a cursor, copy it, and paste it into a plain-text editor, and the original words often come back intact — because they were never removed, only obscured. The same failure mode shows up in Word documents when someone sets a highlight to black or changes font color to match the background: the characters are still present in the document's underlying markup, fully intact, just invisible on screen until someone changes the color back or copies the text elsewhere.
This gap between "looks gone" and "is gone" is sometimes called redaction washing: a visual treatment that satisfies a screenshot or a quick read-through but leaves the actual sensitive content sitting in the file, one copy-paste away from exposure.
Documented failures
This is not a theoretical risk. It has produced real, publicly reported incidents.
Paul Manafort court filing, January 2019
In a memo responding to Special Counsel Robert Mueller's office, Paul Manafort's defense team submitted a PDF with several passages covered by black highlighting rather than true redaction. Reporters covering the filing selected the text behind the black bars, copied it, and pasted it into a text editor. The recovered text confirmed that Manafort had shared 2016 campaign polling data with Konstantin Kilimnik, a business associate the government said had ties to Russian intelligence — a detail the defense had tried to keep out of the public record. The story was widely covered by Reuters, the New York Times, and the Washington Post at the time.
TSA Standard Operating Procedures manual, December 2009
The U.S. Transportation Security Administration posted its airport-screening Standard Operating Procedures manual on a federal contracting website with sensitive sections "redacted" using the same black-bar-over-text approach. The underlying text was still recoverable, and once bloggers and journalists extracted it, the document exposed specifics of screening exceptions and calibration settings that TSA had classified as Sensitive Security Information. TSA confirmed the leak and took disciplinary action; the incident was reported by Wired, CNN, and other outlets at the time.
Both incidents share the same root cause: someone assumed covering text visually was equivalent to deleting it, and nobody verified otherwise before the document left their control. Neither team was careless in the ordinary sense — these were legal and federal agency workflows with review processes. The tooling simply never removed what it appeared to remove.
Why it keeps happening
Drawing a shape over text in a PDF editor, or applying a black highlight in Word, takes seconds and looks finished immediately. Genuinely removing text — deleting the underlying characters rather than layering something over them — requires a tool that parses the document's structure, finds the specific PII inside it, and rewrites the content itself. Most everyday PDF annotation tools were built for markup and commentary, not permanent removal, so "cover it with a box" became the default move even in workflows — legal filings, government disclosures, medical exports — where the underlying text is exactly what needs to disappear.
The failure is invisible until someone checks. A document can pass every visual review, every printed proof, every screenshot comparison, and still contain the full original text one click away.
You have to verify, not trust
The only reliable test for redaction is mechanical, not visual: extract the text from the "redacted" regions and confirm nothing comes back. If a tool cannot show you that the extraction returns empty for the areas it claims to have redacted, you don't actually know whether the redaction held — you only know it looked right on screen.
That test also has to be repeatable by the person relying on the document, not just asserted by the vendor who produced it. A claim of "we redacted it properly" is not verification. Running a text-extraction pass yourself, on the actual output file, is.
The on-device difference
True redaction means detecting the PII inside a document's actual text and replacing or removing it there — not painting over it. anonym.plus does this entirely on-device: it uses Microsoft Presidio and spaCy NLP models, bundled directly into the desktop application, to locate PII across 340+ entity types inside the document's real content, then rewrites that content so the original characters are gone, not merely covered. Nothing about that detection step requires a network call. No document, and no description of what's inside it, has to travel anywhere for anonym.plus to decide what a name, a case number, or a medical record ID looks like.
An independent penetration test conducted in March 2026 confirmed zero outbound network calls during document processing. Disconnect entirely — turn off Wi-Fi, pull the cable — and anonym.plus still detects and removes PII normally, because the whole pipeline runs locally. If a redaction step needs a cloud call, the document, or a description of its contents, has left your control the moment that call goes out, regardless of what encryption wraps around it in transit.
That's the distinction to insist on. The fix for the black-box problem isn't a better-looking overlay or a stronger promise about what a vendor's server does with your file — it's removing the round trip entirely. If a PII tool needs the internet to work, your data still leaves your control at some point. anonym.plus's answer isn't "we encrypt it in transit"; it's that the text never leaves the device it started on. Anything anonym.plus encrypts for storage uses local AES-256-GCM, under a one-time license with no account required — and because it runs offline, you can verify the output yourself, on the same air-gapped machine, with no vendor claim to take on faith.
Beyond government filings
Court filings and federal manuals are where these failures make headlines, but the same tooling gap sits underneath everyday work in any regulated field: a law firm producing discovery documents, a clinic exporting a record before sharing it with a specialist, a bank preparing a file for an auditor, an HR team redacting a complaint before it goes to outside counsel, a company anonymizing support tickets before handing them to a vendor. Every one of these is a document that will leave the originating team's direct control. If the redaction is a visual overlay rather than a real removal of the underlying text, the same failure that exposed a defendant's private communications or an agency's screening procedures can just as easily expose a patient's diagnosis, a client's account number, or an HR complaint's details.
The fix is the same regardless of industry: don't cover PII, remove it — and don't take anyone's word that it worked. Verify it yourself, on your own machine, without needing to trust what happens to the file once it's out of your hands.
Redact PII on your own device, then verify it yourself. See anonym.plus → or compare it to other anonymization tools →.