DEV Community: PDFnoted

Your PDF Has Three Layers. The One You Check Isn't the One That Leaks.

PDFnoted — Thu, 29 Oct 2026 16:59:08 +0000

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.

Three kinds of PDF watermarks, and why most removers only handle one

PDFnoted — Wed, 28 Oct 2026 13:13:54 +0000

"Just remove the watermark" is one of those tasks that sounds trivial until you open the file. I've lost count of how many times someone has told me a tool "doesn't work", when the real issue was that they were dealing with a different kind of watermark than the tool was built for.

There are three, and they live in completely different places in the file.

Type 1: an annotation

This is the easy one. The watermark is an object in the page's /Annots array — the same mechanism as a sticky note or a highlight. It's drawn on top of the page, but it isn't part of the page content.

Anything that can edit annotations can delete it. On the command line:

# see what annotations exist
pdfinfo -meta file.pdf
qpdf --show-object=trailer file.pdf | head

Most "PDF watermark remover" tools stop here. Which is fine, as long as that's what you actually have.

Type 2: a Form XObject

This is where it gets interesting. The watermark is a reusable content object referenced from the page's resource dictionary and painted via a Do operator in the content stream. It is page content now — there's no annotation to select and delete.

Removing it means:

finding the XObject in /Resources /XObject
following the mapping through /Form and the Matrix × Do CTM combination (a naive search misses nested forms)
deleting the object and its reference
writing the stream back and clearing the stale filter keys (Filter, DecodeParms, F, FFilter, FDecodeParms, DL)

Step 2 is why simple text-matching approaches fail. The content stream is compressed, the object may be nested several levels deep, and the positioning math is composed at draw time rather than stored as coordinates.

Type 3: baked into a scan

If the PDF is a scanned image, the watermark is pixels. No PDF-level tool will remove it — that's image editing, and results are usually ugly.

Worth checking before you try anything else:

pdftotext file.pdf - | wc -c

If that returns almost nothing, you're looking at a scan. Stop trying PDF tools.

How to tell which one you have

Quick heuristic:

pdfinfo file.pdf | grep -i pages
pdftotext file.pdf - | head -20        # text present?
qpdf --qdf --object-streams=disable file.pdf out.pdf
grep -a -n "/Annots\|/XObject\|/Watermark" out.pdf | head

If /Annots shows up with a /Subtype /Watermark entry, it's type 1. If you find /XObject forms that don't correspond to visible images, it's probably type 2.

The part that actually matters

Whatever you remove, verify afterwards. A lot of tools — including some well-known paid ones — "remove" content by drawing an opaque rectangle over it. The underlying text is untouched and trivially recoverable:

pdftotext cleaned.pdf - | grep -in "confidential\|salary\|身份证"

If that prints anything, the file is not clean. I've seen contracts go out to counterparties with the "redacted" salary figure still in the text layer, because whoever prepared it trusted the visual preview.

For type 1 and 2, a proper removal should survive this check. For type 3, it won't — and that's the honest signal that you need a different approach.

Disclosure: I work on PDFnoted, which does object-level watermark removal and re-scans the file after cleaning. The three-type distinction here is tool-independent though — knowing which one you have will save you most of the time regardless of what you use.