Privacy·August 1, 2026·12 min read

Blacking Out Text in a PDF Doesn't Actually Remove It

A black box or highlight over text in a PDF only changes what the page looks like, not what the file stores. This article covers why the underlying text is almost always still recoverable, five real cases where that mistake became public, including Meta and the DOJ, and what actually removes text for good.

In April 2025, Meta's own legal team made this exact mistake during a live FTC antitrust trial. Covering competitor data from Apple, Google, and Snap with black boxes instead of actually removing it, they submitted slides that anyone could copy and paste to read what was supposedly hidden. If a company with an entire legal department and a courtroom full of scrutiny can get this wrong, a black rectangle drawn in a word processor or PDF viewer is not a safe way to hide anything.

It's an easy mistake to make, because a black box looks exactly like redaction on screen. Most people assume that painting over sensitive text removes it the same way deleting a sentence does. It doesn't. This article covers why the text is almost always still there, five real cases where that gap became public, and what an actual redaction tool has to do differently to fix it.

TL;DR: drawing a black rectangle, highlight, or comment over text in a PDF only changes how the page looks, not what's stored in the file. The words themselves live in the page's content stream, a separate part of the file from whatever box or shape sits visually on top of them, so copying the text out, or running an extraction tool, usually recovers it in full. Flattening the file doesn't reliably fix this either. Real redaction has to delete the underlying text, not cover it.

Does Blacking Out Text in a PDF Actually Remove It?

No, it doesn't. Drawing a black rectangle, a highlight, or a comment box over text in a PDF changes how the page looks on screen, not what's actually stored in the file. The words underneath are almost always still there in full, and in most cases you can pull them back out with nothing more than a mouse and a text editor.

You can check this yourself on any PDF you've already covered this way. Open the file, click and drag your cursor across the blacked-out area as if you were selecting normal text, then copy it. Paste that selection into a plain text editor, Notepad, TextEdit, anything that strips formatting. If words show up where the black box was, the text was never removed, only hidden behind something drawn on top of it.

This is consistent with how Adobe scopes its own documentation for the dedicated Redact tool. It's described as built to permanently remove marked content, unlike an ordinary comment, highlight, or shape tool, which only adds a new object to the page without touching what sits underneath. Covering text and deleting text are two different operations, even though they can look identical once you're staring at the finished page.

This holds regardless of which app drew the box in the first place. A black rectangle added in Word before exporting to PDF, a highlight applied inside a PDF viewer, or a shape drawn with a comment tool all behave the same way once the file is saved. None of them touch the text itself.

Why Is the Text Still There Even Though You Can't See It?

A PDF page stores two separate things in two separate places. The words themselves are written as text-drawing instructions inside the page's content stream, and any box, highlight, or shape drawn over them lives as its own separate object, layered on top when the page renders. Painting over the box doesn't touch the content stream underneath it, because the two were never connected to begin with.

That's why copying text out, or running any text-extraction tool against the file, works the way it does. Those tools read the content stream directly, the actual instructions that say which characters get drawn where, and they have no reason to check what's sitting visually on top of that content when the page displays. A black rectangle placed over a paragraph is invisible to a process that never looks at the rendered page in the first place. It only reads the underlying instructions.

The box itself usually exists as one of two kinds of object: an annotation, the same category PDF uses for comments and highlights, or a shape drawn directly into the page content by whichever app created it. Either way, it's a distinct object from the text it's covering, added afterward and sitting in its own layer, not a change to the text operators themselves.

When I built the redact tool on JoyPDF, this is the exact distinction the feature has to handle correctly. A real redaction has to reach into the content stream itself and delete the text-drawing operators for the marked area, not just add a shape that sits above them. Anything short of that, drawing a box, applying a comment, painting a highlight, leaves the original operators untouched, which is exactly what makes the text recoverable, even when nobody removes it on purpose.

Doesn't Flattening the PDF Fix It?

No, not reliably. Flattening a PDF merges its visible layers, the page content, comments, form fields, and drawn shapes, into a single flat layer, so a black box looks permanently stuck to the page instead of sitting on top as a separate, removable object. But merging what's visible doesn't necessarily delete the original text-drawing instructions the box was covering, which can still be sitting underneath the flattened result.

This is probably the single piece of advice most likely to give someone false confidence. Flattening solves a different problem: it stops a viewer from letting someone click and drag the box out of the way, or toggle a comment layer off. It doesn't touch the mechanism covered above: the separation between what a page shows and what its content stream stores. So a flattened black box can still have fully recoverable text hiding directly underneath it.

If you've flattened a document and are relying on that step alone, it's worth running the same copy-and-paste check described earlier before you send the file anywhere, because flattening was never designed to solve this particular problem.

Real Cases Where a Black Box Didn't Work

This isn't a hypothetical. In the last several years, a black box that didn't actually redact anything has exposed sensitive material belonging to a presidential campaign chairman's legal team, a Fortune 500 company in a live federal antitrust trial, and the Department of Justice, among others. These aren't small, one-person mistakes. They're legal teams with real resources behind them.

This also isn't a new problem. A 2011 analysis by Princeton's Center for Information Technology Policy manually examined a sample of roughly 2,000 US federal court filings on PACER that used hand-drawn redaction boxes and found around 194 of them had failed, with the underlying text still recoverable. That figure describes one specific sample from over a decade ago, not a current rate across all PDFs, but it shows this has been a recurring failure for a long time, not a one-off.

The most widely reported recent case is Paul Manafort's January 2019 sentencing-related court filing, where his defense team covered sensitive passages with black boxes instead of true redaction. Vice's investigation into the filing found the mechanism directly: just by copying and pasting the redacted paragraph, it was possible to read the blacked-out parts and find out new details of Manafort's relationship with Konstantin Kilimnik. Columbia Journalism Review's own analysis of the filing identified what those details were: a Ukraine peace-plan discussion and campaign polling data shared during the 2016 election.

A similar failure hit TikTok in October 2024. Black-bar redactions in a complaint filed by Kentucky's Attorney General were copied and pasted to recover roughly 30 pages of internal TikTok material on teen usage patterns, according to NPR's reporting on the lawsuit.

Meta's own legal team made the same mistake in April 2025, during a live FTC antitrust trial, submitting slides that covered competitor data from Apple, Google, and Snap with black boxes instead of removing it. Daring Fireball described exactly what went wrong: the botched redactions were just objects layered atop the supposed-to-be-redacted material in a PDF file, leaving the original layer's content intact but just visually occluded.

The most recent example is the Department of Justice's own December 2025 release of Epstein-related court filings. Mediaite reported that the redacted text remained as selectable text beneath black boxes, and that anyone who copied the blacked-out portions could paste them into a separate document to reveal the hidden content.

This failure mode isn't new, either. The TSA's own airport screening manual, posted online with black-rectangle redactions in December 2009, was fully recoverable the same way. Nextgov reported at the time that anyone who copied the document and pasted it into another format, such as Microsoft Word or Windows Notepad, could read the redacted sections. It's a reminder that this has been a known problem for more than 15 years.

YearOrganization or caseWhat was exposedSource
2019Paul Manafort sentencing filingUkraine peace-plan discussion and shared 2016 campaign polling dataVice, CJR
2024TikTok / Kentucky Attorney General lawsuitInternal TikTok material on teen usage patternsNPR
2025Meta / FTC antitrust trialApple, Google, and Snap competitive dataDaring Fireball
2025DOJ Epstein-related court filingsA signed check for over $400,000 to an immigration lawyer connected to Epstein's victimsMediaite

What Actually Removes Text From a PDF?

Real redaction has to delete the underlying text-drawing instructions from the content stream itself, not draw something over them. That's the one job a dedicated redaction tool does that a comment, highlight, or shape tool never does, and it's the difference between a document that's actually safe to share and one that only looks safe on screen.

A genuine redact feature works in two steps. First, you mark the areas that need to go, drawing a box over the text or image you want removed. Second, applying the redaction actually deletes whatever's marked, the text operators themselves, along with any image data sitting beneath it, instead of just painting a black shape on top and calling it finished. Skipping that second step, or using a tool that never had one, is exactly what produced every incident in the table above.

Adobe frames this the same way in its own documentation on redacting a PDF: permanently removing sensitive content and hidden data is important so the information is not passed along when publishing your PDF. That's a description of what a dedicated Redact feature does, and what a comment or drawing tool structurally cannot.

You can redact a PDF properly in your browser with a PDF redaction tool built to actually delete the marked text, which is what I built JoyPDF's redact-pdf feature to do. Because the file is processed on your own device and never sent to a server, that matters if what you're redacting is a client contract, a medical record, or a legal filing. Those are exactly the kind of documents you may not be permitted to hand to a stranger's upload form in the first place.

What Else Might Still Be Hiding in a Redacted PDF?

Even a properly redacted PDF, one where the text itself was genuinely deleted, can still carry metadata, hidden layers, embedded files, comments, or prior-revision history that reveals what was removed or who touched the file. Redacting the visible content and cleaning up everything else the file carries are two different jobs, and finishing only the first one can still leave a trail behind.

This is why a genuine redaction workflow includes a separate sanitize step, distinct from redaction itself. Adobe's own documentation describes a Remove Hidden Information step that strips out information not visible in the file, including comments, metadata, or hidden layers, separately from the redaction pass itself. Skipping it means a document can look textually clean on the page while still carrying details about its own editing history in fields nobody thinks to check.

Once a document is genuinely clean, text removed and hidden data stripped, it's worth thinking about how it travels afterward. If you're emailing a redacted contract or filing to someone, you can add a password before sharing a redacted document externally, so the file itself isn't readable if it ends up in the wrong inbox, and I've covered the mechanics of adding a password to a PDF in more detail separately. If the same document also needs a signature before it goes out, signing a document without uploading it anywhere works the same way redaction should: entirely inside your browser, with nothing sent to a server to get it done.

None of this makes a black box malicious. Most people drawing one assume it works exactly the way it looks like it should. But a box or highlight only changes what the page shows, not what the file stores. The words themselves live in a separate part of the file from anything drawn on top of them, and flattening doesn't reliably close that gap. It's happened to a presidential campaign's legal team, a Fortune 500 company in federal court, and the Department of Justice, as recently as this year. If there's a document sitting on your desktop right now with a black box over something sensitive, it's worth checking whether the text is actually gone before you send it anywhere.

Try JoyPDF tools without uploading files to a server - open the PDF toolkit.