A few months ago I sat in on a document review where someone had "cleaned" a contract before sending it to a partner company in another jurisdiction. They had opened it, deleted two paragraphs, drawn black rectangles over the pricing table, and saved it. It looked clean. It rendered clean.
It was not clean.
We pulled the text out in about ten seconds and read the deleted paragraphs back in full. The pricing table was still there, sitting underneath the rectangles, selectable in any viewer. And the file's metadata still carried the original author's name and the internal filename — which happened to include the client's name and the word "draft."
Nobody in that room had done anything careless. They had done what almost everyone does, which is assume that what you can see on screen is what's in the file.
A PDF isn't a document. It's a container.
This is the mental model that fixes most of these mistakes. A PDF is closer to a zip archive than to a piece of paper. It has:
- A page layer — the content stream that draws text and images. This is what you see.
- An annotation layer — comments, highlights, form fields, and yes, those black rectangles.
- A metadata layer — title, author, company, creation tool, modification dates, sometimes GPS coordinates.
- An object layer — embedded fonts, images, attachments, and in many cases, previous versions of the file.
Most people only ever inspect the first one.
Layer one: the rectangles
The single most common false sense of security in document handling is the black box.
When you draw a rectangle over text in a PDF editor, you are adding an annotation or a filled shape on top of existing content. The text underneath is untouched. It's still in the content stream. Ctrl+A, Ctrl+C, paste into a text editor, and there it is.
Real redaction removes the text from the content stream itself. Not covers it — removes it.
The test is simple and takes about ten seconds:
pdftotext document.pdf - | grep -i "confidential"
If that returns a hit on something you thought you'd removed, the redaction didn't happen. No amount of visual inspection will tell you this, because visually the file looks perfect.
The same applies to white-on-white text. Some tools "delete" content by turning it white rather than removing it. It disappears on screen, stays in the file, and comes straight back the moment anyone extracts the text.
Layer two: metadata
Metadata is the layer nobody checks, because there's no visual cue that it exists.
Word, Google Docs, and most PDF exporters embed author name, company, creation and modification timestamps, and the original filename. Filenames are the underrated leak here. Acme_NDA_v3_FINAL_draft_internal.pdf tells a counterparty more than most people intend to.
On mobile-generated PDFs and some scanners, you can also get GPS coordinates.
Check it with:
pdfinfo document.pdf
Or in most viewers, File → Properties. If you see a name that shouldn't be there, it shouldn't be there.
Layer three: what the file remembers
This is the layer that surprises even technical people.
PDFs support incremental updates. When a file is edited and saved, the change can be appended to the end of the file rather than rewriting it. The old bytes stay. "Save as" does not reliably strip them, and neither does most PDF editing software by default.
What this means in practice: a file can contain an earlier version of itself, and a determined recipient can recover it.
A reasonable check:
strings document.pdf | grep -i "internal\|draft\|confidential"
Crude, but it catches the overwhelming majority of real-world cases. If you want to be thorough, compare the file's declared size and object count before and after a proper flatten-and-rebuild pass.
Why this matters more across borders
Domestically, a metadata slip is usually embarrassing. Cross-border, it can be a compliance event.
Data protection reviews — GDPR, PIPL, whatever framework applies — tend to focus on what's intentionally in the document. Consent, lawful basis, transfer mechanism, retention. Those are the right things to focus on. But the leak that's hardest to notice is rarely the visible content. It's the author field, the filename, the deleted-but-not-deleted paragraph, the previous version sitting in the file.
And unlike a policy failure, this one is trivially preventable. It's a five-minute check.
A checklist that takes five minutes
Before any sensitive PDF leaves your organization:
-
Extract the text and search it.
pdftotext file.pdf - | grep -i "confidential\|internal\|draft". If it hits, the content is still there. -
Read the metadata.
pdfinfo file.pdf, or File → Properties. Clear anything you wouldn't want a counterparty to see. - Redact properly, don't cover. Use a tool that removes content from the stream, then verify with step 1. Never trust the visual.
- Rebuild, don't just save. Flatten the file so incremental history is dropped.
- Re-run step 1 after every edit. This is the step people skip, and it's the only one that actually proves anything.
None of this requires buying anything. Every command above ships with poppler, which is a one-line install on every platform. The hard part isn't the tooling — it's getting into the habit of verifying rather than assuming.
The uncomfortable version of this advice: if you've never run step 1 on a file you considered clean, it's worth doing once. It's a five-minute experiment and it tends to change how teams handle documents.
Top comments (1)
The pattern connecting layers one and three is that both come from editing on top of the original bytes instead of producing a new file. The habit that fixes both is to treat the outgoing PDF as a build artifact: redact in the source, export a fresh file through a full rewrite (print-to-PDF or a qpdf rewrite) rather than saving the edited original, then run the pdftotext/pdfinfo/strings checks on that final artifact as a send gate. One caution on the tests themselves: a grep hit proves the leak survived, but a clean grep only proves that one check passed - which is why the rewrite-first habit carries more weight than any single verification step.