DEV Community: Haruo

Find out whether a PDF was edited, with one curl and no signup

Haruo — Wed, 02 Sep 2026 12:39:26 +0000

The thing that took me longest to internalise about this file format: a PDF is not a picture of a document. It is an append-only container with a linked list of revisions in it, and it keeps receipts about its own history whether or not anyone wanted it to.

Which means "was this edited after it was made?" is often answerable from the bytes, deterministically, with no model involved. Here is how to ask, in one command, without an account.

The call

curl -s https://tamperlens.com/api/v1/inspect \
  -F file=@statement.pdf

No Authorization header. Anonymous callers get the full report, rate limited to 10 documents per hour per IP. The cap is 10 MB per document, the bytes are parsed in memory and discarded when the response is written, and there is no human review step.

A raw body works too, if your HTTP client makes multipart expensive:

curl -s https://tamperlens.com/api/v1/inspect \
  -H "Content-Type: application/pdf" \
  --data-binary @statement.pdf

The format is decided by sniffing the bytes, never from Content-Type or the filename. A phone that renamed a JPEG to .pdf is analysed as the JPEG it is. Word, Excel and PowerPoint files and JPEG, PNG, WebP, HEIC and AVIF images go to the same endpoint and come back in the same report shape, with a mediaType discriminator.

What comes back

{
  "id": "insp_2f1e9c04-...",
  "engineVersion": "1.37.0",
  "summary": {
    "riskScore": 10,
    "riskBand": "low",
    "signalCount": 1,
    "revisions": 1
  },
  "signals": [
    {
      "id": "producer-fingerprint",
      "severity": "low",
      "title": "PDF editing tool in the production chain (iLovePDF)",
      "detail": "The document's metadata names iLovePDF in its production chain. ...",
      "evidence": {
        "tools": ["iLovePDF"],
        "origin": "pdf-editor",
        "producer": "iLovePDF",
        "creator": "iText 7.2.5",
        "revisions": 1
      }
    }
  ],
  "document": {
    "pages": 2,
    "producer": "iLovePDF",
    "creator": "iText 7.2.5",
    "creationDate": "2026-01-04T10:02:00.000Z",
    "modDate": "2026-01-06T18:41:00.000Z",
    "encrypted": false,
    "signed": false,
    "revisions": 1,
    "sizeBytes": 184320
  },
  "disclaimer": "Tamperlens reports risk signals, not authenticity verdicts. ..."
}

Three things to know before you write any code against it.

riskBand is low under 30, elevated 30 to 69, high at 70 and above, and the high band is narrow on purpose: it is reserved for reports containing at least one high-severity signal, so a pile-up of weak findings is clamped at 69 and can never reach it. That is a contract, not an accident of the arithmetic.

signals[].id is a stable string. Branch on ids rather than on the score when you know your own domain, and you will: if your flow legitimately involves customers signing documents, you want incremental-updates weighted down (a signature is an incremental update) and signature-coverage weighted up.

signals[].evidence is the part a human reviewer needs. It is small, it contains no document content, and it is per-family and additive, so read keys defensively. Store it next to the decision it produced.

Build a positive before you trust a negative

This is the part I would actually do first, and it takes about four minutes.

Take a PDF whose history you personally know: something you generated, or a statement you downloaded straight from a bank. Inspect it. Then run the same file through any free browser-based PDF editor, change one number, download it, and inspect that.

You can watch the mechanism before the API even answers:

$ grep -c '%%EOF' statement.pdf
2

A PDF ends with %%EOF. Two of them is the format's own record that something was appended after the original save. Every appended cross-reference section's trailer carries /Prev, the byte offset of the previous one, which is a backwards linked list you can walk to the original document.

The count alone is weak evidence, and you should treat it that way: signing a document is an incremental update, so is filling in a form field, and a linearised "fast web view" file legitimately has two markers from a single save. The strong version is what the appended revision replaced. A later revision that replaces an object which already existed, and that carries page or content-stream data, has no reading compatible with "the issuer generated this and nobody touched it."

Watching which signals light up on a file whose history you know is worth more than any vendor's page, including mine.

Send your decision rule with the request

You will otherwise reimplement if (riskScore >= 70) on your side, slightly differently from everyone else, and invisibly to whoever you ask about it later.

curl -s -X POST https://tamperlens.com/api/v1/inspect \
  -H 'X-Tamperlens-Policy: {"review":30,"reject":70,"rejectOn":["redaction-exposure"]}' \
  -H "Content-Type: application/pdf" \
  --data-binary @statement.pdf

The response gains one block and nothing else changes:

"policy": {
  "verdict": "reject",
  "riskScore": 45,
  "thresholds": { "review": 30, "reject": 70 },
  "reason": "signal",
  "triggeredBy": ["redaction-exposure"]
}

Four behaviours worth knowing, because each is a decision:

The defaults are the engine's own band boundaries, so an unconfigured policy agrees with riskBand instead of quietly disagreeing with it.
A named family beats a threshold, and rejectOn beats reviewOn. Naming a family means it matters regardless of what the arithmetic came to, and a threshold that could veto that would make the rule advisory.
Unknown signal ids are accepted and never match. A family we rename must not be able to take your pipeline down.
A malformed policy is a 422, never a silent fallback to our defaults. A typo that leaves you believing a rule is enforced when it is not is the one failure mode this must not have.

Errors worth writing code for

Status	Body	Do
`413`	`{"error":"file_too_large","maxMb":10}`	check size client-side first
`422`	`{"error":"analysis_timeout","timeoutMs":15000}`	do not retry, the input is the problem
`429`	`{"error":"rate_limited","retryAfterSeconds":60}`	you called too fast
`429`	`{"error":"quota_exceeded","quota":25,"used":25}`	queue, do not drop, the counter resets monthly
`503`	`{"error":"busy","retryAfterSeconds":5}`	retry with backoff, `Retry-After` is set

rate_limited and quota_exceeded are deliberately distinct: a quota is the plan you bought, a rate limit is the pace you called at.

And the one that catches people out: a file the parser cannot make sense of is not an error. Unparseable and hostile input degrades into a 200 carrying a structure-warnings signal. A garbage PDF is a finding, not a failure, and treating it as a 5xx would mean throwing away the most interesting document of the day.

Two properties you can build tests on

It is deterministic. Identical bytes produce an identical report apart from id. Pin your fixtures, snapshot the reports, and regression-test the vendor: that is an explicitly supported use of the free tier. Pin engineVersion while you are there, because a bump means the scoring weights may have moved.

Nothing is stored. No document is written to disk, no document content is logged, no third party is in the analysis path, and no outbound call happens while inspecting. What persists is a usage row that holds no document.

If the caller is an agent

An agent that opens an attachment has already read whatever the attachment says, and a PDF is a convenient place to put a sentence addressed to the model rather than to the person. So the useful order is inspect, then read: one call before the bytes reach your model's context, branching on the injection families exactly as you would on any other signal.

The payload does not have to travel with the finding:

curl -s -X POST 'https://tamperlens.com/api/v1/inspect?redact=payload' \
  --data-binary @resume.pdf

Every attacker-authored string is elided and the signal gains evidence.payloadRedacted: true, so "nothing was found" stays distinguishable from "you were not given it". The score, the band and every count are identical.

There is an MCP server over the same endpoints, npx tamperlens-mcp, which redacts unconditionally, because an MCP tool result is a model's context.

What a clean report does not mean

The honest limit, and I would rather write it than have you find it.

The engine reports what is true of the bytes. A structural signal can be defeated: flattening a page to a raster image throws away almost everything there is to read, printing the file from a browser rewrites its whole account of itself, and stripping the metadata and then rewriting the file removes both the metadata and the history in one go. I published the whole matrix of what defeats each of my own signals, with the cells I got wrong, because the alternative is a reader who sees a clean report and hears "this document is genuine".

Those are different claims. A clean report means the bytes are clean.

So the report is a set of signals and never a verdict. "This file contains two revisions, a later revision replaced a page content stream, and the Info dictionary names an online PDF editor that the XMP packet does not" is a statement about bytes that a human can act on. "This document is fraudulent" is a statement about a person, and a parser does not get to make it.

The one-screen quickstart is at tamperlens.com/api, the full schema and every error code at /api-reference, and the machine-readable spec with a try-it console at /docs. If you would rather drag a file into a page than write a request, the free checker returns the same report, with the raw evidence under every finding and no account involved.

If a signal fires on something you know to be completely innocent, that is the comment I want most. Those are the interesting ones.

A published invariant is a test you have not written yet

Haruo — Tue, 01 Sep 2026 18:36:56 +0000

Three places in our product said the same thing about a report:

One report contains at most one signal per family. A family either fires once, with all its findings collected into a single evidence object, or it does not appear at all.

The public field guide says it. docs/ARCHITECTURE.md restates it. And engine/message.ts relies on it, mapping a family id to a single explanation on the strength of it.

Nothing enforced it. Three families had never obeyed it, on our own checked-in fixtures:

office-doctype.docx            office-structure-anomalies [medium] [low] [info]
office-macro-template.docx     office-active-content      [high] [medium] [medium]
office-injection-markers.docx  office-hidden-content      [medium] [low]

Three consumers had been built on a promise that nothing was keeping. This is what it cost, what the fix looked like, and the one violation we decided to publish instead of repair.

Three things went wrong at once, and none was visible from inside the family

The score inflated. scoreSignals decays the second and later signals of a given severity, on the assumption that they are different families corroborating each other. That is a good assumption and it is the reason the score is not just a sum. A family emitting three findings therefore collected three independent contributions for one finding. office-macro-template.docx scored 100 where the same evidence now scores 70: high 70 plus medium 25 plus medium 25 is 120, clamped to 100. Two more fixtures moved with it, 100 to 95 and 35 to 30.

Worth noting what did not move: no fixture changes risk band. The fold always keeps the strongest finding, and the band turns on the presence of a severity rather than on how many findings carried it, so high stays high. That is the difference between a scoring bug and a detection bug, and it is why nobody noticed for as long as they did.

One number meant two things. summary.signalCount is what the report headline prints. It counted findings on Office files and families everywhere else. A single API field with two definitions, decided by which engine ran.

The UI repeated itself. The report card keys a signal's brief text and its "What this signal means" link by family. So three signals of one family rendered three identical cards with three identical links.

None of those three failures is visible from inside the family that caused them. They live in the scorer, in the summary, and in the renderer, which is the general shape of an invariant violation: the family that breaks it is never the code that pays.

The fold, which is not a summary

The fix is a shared helper, src/engine/fold.ts, generalised from code one PDF family had used since engine 1.14.0.

The strongest finding keeps its title and its whole paragraph, so a reader gets the full explanation of the thing that mattered most.
Every other finding appends one sentence through notes, a mechanism two families already used.
No evidence is dropped. Every check's evidence object is merged whole.
evidence.checks names which checks fired, so a consumer can branch without reading prose.

That last point is the one I would carry to another codebase. A fold that summarises is a fold that loses data, and the loss shows up months later in a support thread. A fold that merges and then names what it merged costs one array and turns "did the doctype check fire?" into a lookup instead of a string match against a title that copy review is free to rewrite.

Making the merge lossless took two evidence-key renames: two different checks had both been writing parts, so merging them would have silently dropped one. If you are folding evidence objects, the collisions are the work.

One family did not move onto the helper, deliberately. embedded-image-anomalies keeps its own inline copy, because the strings in its evidence.checks are evidence key names rather than check names. That is a shipped shape in a public API, and changing it would have been a breaking change with no defect behind it. Consistency inside the engine is worth less than a stable contract outside it.

The duplicate that no amount of folding could prevent

Folding inside a family fixes a family that emits three. It does nothing about a registry that appends a fourth.

Ours did: a coverage-disclosure family was in the registry's loop and was appended again by the loop's failure path, for any family that threw. So it ran twice on exactly the documents that had gone wrong.

It left the loop. It now runs last, once, and is handed the list of families that threw. Which is what the comment beside it always claimed it did.

The always-on coverage disclosure also repeats in full when it becomes a note rather than being shortened, and that was a choice: an abbreviated statement of what was not looked at is not a disclosure.

The exception we published instead of fixing

One family still emits two signals, knowingly.

redaction-exposure reports a filled box drawn over text (high, conclusive) and a picture drawn over text (info) as separate findings. Merging them was the earlier behaviour and it was a measured bug: one document announced four exposed text runs at high severity when three of them were a letterhead. The two findings also carry the same evidence keys at different scopes, so the fold above would silently drop one set of numbers.

Resolving it properly means either nesting that family's evidence or changing the published sentence, and both are decisions about what the product promises rather than refactors. So the exception is now stated in all three of the places the invariant is stated: on the public page, in the architecture doc, and in the test that enforces it, each carrying the argument for why.

The alternative was leaving a sentence on a public page that the engine disagrees with, which is the failure mode this whole exercise exists to fix. An exception you state is documentation. An exception you leave implicit is a lie with a timestamp on it.

The test, and the two things it does that a normal test would not

test/engine/one-signal-per-family.test.ts:

It runs all three engines over every fixture in the repository, enumerated from the directory rather than from a list. The defect was in the Office engine, and the test is not a case in the Office suite, because the property is about all three and the one that broke it was the one nobody was looking at. Enumerating the directory is the other half of that: a fixture added tomorrow is checked tomorrow.
It collects every violation before asserting, rather than stopping at the first. A test that fails on the first violation makes you fix and re-run once per instance, which is how you end up believing you are done.

Each engine also carries a floor ("fewer than 60 PDF fixtures means the sweep stopped seeing them"), because a glob that silently matches nothing is a green test.

It found a fourth violating fixture the review had not, which is how the redaction-exposure exception came to light in the first place. It also pins that summary.signalCount counts families rather than findings, on all three engines, because the invariant and the count are the same promise stated twice.

The other half: a published number needs a derivation, not a reviewer

Two counting bugs turned up next to this one, and they rhyme.

A coverage test had been counting Office families with a regex over the source of a private array. It read the right number on the day it was written. It would have read 7 the moment the disclosure family left that array, which is precisely what this refactor did. It imports an exported constant now. A published number that a refactor can quietly change is the failure this repository keeps rediscovering.

And a family count was baked into a PNG. The social card for the flagship guide said "All ten signal families" while the guide's own heading said eighteen, and that card is the og:image on ten pages. The sweep that checks every count on the site could not see it twice over: the string lives in a build script outside the sweep's roots, and what ships is an image, which no text lint can read. So a test now reads the card generator's source and derives the expected number from the engine's own registry.

The rule under all three: if you publish a number or an invariant, you owe it a derivation. Not a reviewer, not a style note, not a comment. A reviewer does not count families across ninety-six pages, and a comment cannot fail CI.

The invariant, the eighteen families it applies to and the one stated exception are in the fraud signals field guide. If you want to see the report shape the invariant is about, the free checker takes a PDF and gives back the same JSON the API returns, with the evidence under every finding. No account, and nothing is stored.

If you have shipped a guard that turned out to be enforced at the wrong granularity, I would like to read about it. That is the class of bug I now assume I have more of.

The half of Claude's watermark you can actually check

Haruo — Sat, 15 Aug 2026 17:29:47 +0000

Sylwia Lask's post on Claude's watermark is the best-natured thing I have read on this topic in a while, and it is right about the two things people keep getting wrong: the EU AI Act asks for machine-detectability, not a ban, and a watermark hit tells you a model was involved, not that it wrote anything.

I want to add to it rather than argue with it, because that announcement has two halves and the comment threads only ever reach one of them.

Half one is text. A keyed statistical mark, spread across token choices. It is the half everybody is discussing and, as I will get to, the half you personally cannot test.

Half two is files. Anthropic began attaching C2PA content credentials to generated images on 11 August. C2PA is an open standard with an open reference tool, so this half is checkable by anyone, today, with no key and no vendor cooperation.

I build a PDF signal engine, so the second half is my problem. On 14 August I put a signed image through every PDF generator on this laptop to find out what a downstream reader can still see. That is the measured part of this post. First, though, two things about the text half, because both keep coming up in that thread.

The mechanism has a specification you can read

The post reasons from first principles to statistical token watermarking, which is the right guess, and it is careful to label it as a guess. Since then the guess has been confirmed, in that post's own comment thread: on 14 August the author notes that Anthropic updated its documentation and Claude is indeed using SynthID. Anthropic's page puts it as a version of the SynthID-Text approach published by Google DeepMind.

That fact deserves to be out of a comment thread and in front of people, because it changes the epistemic status of the whole conversation. There is one scheme here, not two, and it has a specification: Nature 634, 818-823. You do not have to guess at the mechanism, you can read it. As the model writes, it hashes the last few tokens with a secret key and uses that seed to bias which of several equally good next words it emits. In unmarked text those tokens arrive at chance rate, so counting them gives a z-score and an actual p-value. That is the real advantage over a classifier: a calibrated false-positive rate instead of a vibe.

It also means the published attacks apply directly, which is the part most coverage still misses while calling the mechanism undisclosed. "Undisclosed proprietary magic" and "a published scheme with known attacks" support very different decisions.

It is not invisible characters, and stripping them does nothing

The post gets this right and it is worth repeating, because stripping invisible characters is the first thing everyone reaches for: the mark is not zero-width Unicode. Not U+200B, not U+FEFF, not the tag block.

I know those characters well, because our text extraction strips them before anything else reads the text, for prompt-injection reasons that have nothing to do with watermarking. Which gives me the two-sided version of the myth:

Removing every invisible character from a paragraph does nothing to a statistical watermark. The signal is in which words were chosen, not in anything you can see or delete.
Finding invisible characters in a document proves nothing about Claude either. They arrive from copy-paste, from CMSs, from PDF extraction. The presence of a carrier is not evidence of a payload.

What does remove the mark is documented and cheap. Re-tokenisation, which is as simple as inserting a character between every word and deleting it again, destroys the n-gram contexts every hash-based scheme seeds from. OpenAI names that attack in its own writing on why it never shipped text watermarking. Paraphrase removes it outright below roughly 800 tokens. And Jovanović, Staab and Vechev, ICML 2024 showed that for under $50 an attacker can both spoof and scrub state-of-the-art schemes, with over 80% average success. Spoofing is the direction nobody plans for: forging a mark onto human text is the attack that hurts a person.

Then there is the gate that ends the practical conversation. The scheme is symmetric. Without the secret key you cannot reconstruct the seeds, and without the seeds there is nothing to count. For a third party holding a suspicious paragraph, the answer today is not "run the test and see". The test cannot be run at all.

The fallback everyone reaches for instead, a commercial AI-text classifier, is worse than its reputation: 61.22% of human-written TOEFL essays flagged as AI by seven detectors in Liang et al., 78.3% of granted patent claims flagged by a leading open detector, and around two dozen universities that switched their detector off and none that switched it back on. I keep the receipts for that in a guide, how to detect AI-generated text, which mostly exists to explain why the honest answer to the question is "you cannot, and here is what you can ask instead".

That is the whole text half. A sound scheme, a key you do not have, and known attacks. Which is why I spend my time on the other half.

The half you can check: what happened to nine PDFs

C2PA is not an AI detector. It is a signed manifest inside the file with a hash binding the claim to the bytes, so it is a first-person statement you can verify. My question is narrower than "is this AI": it is does what a file declares about itself still validate, and does the declaration survive the trip to wherever a reviewer opens it.

Fraud review sees PDFs. Anthropic signs .svg, .png and .jpg. So the question is what happens when a signed image goes into a document, and as far as I can tell nobody had measured it. I built 30 files and 9 PDFs on one machine on 14 August, with local tools only, using c2patool 0.27.15's development certificate for signing.

A signed JPEG survives PDF embedding, byte for byte. Six of six paths: img2pdf, Chrome print-to-PDF at natural size and scaled to 47%, Ghostscript two ways, and qpdf --linearize. The DCT stream comes out of the PDF identical to the one that went in, and re-validates. I had assumed Chrome's print pipeline re-encoded and it does not: the scaling is applied by the content stream's transformation matrix instead.

PNG and SVG survive nothing. Zero of two and zero of one. A PDF has no PNG container, so the pixels are re-emitted as a Flate raster and the caBX chunk, which is a PNG chunk, has nowhere to go. Chrome draws an SVG as vector operators and produces no image object at all. Of the three formats Anthropic signs, exactly one carries its credential into a document, and it is the one document fraud actually uses.

And here is the result I did not expect. c2patool returns Error: No claim found on all nine PDFs, including the six whose embedded JPEG carries a fully valid manifest. The official reader looks for a PDF-level manifest. The credential is sitting one indirection away, inside an image stream, intact and unread.

So the honest summary of the file half is: the credential survives the trip, and the standard tool for reading credentials will tell you the document is unsigned. If you want to find it you have to walk the object graph, pull the image streams out and validate those.

Two more numbers from the same run, both of which cut against the optimistic reading:

Five of five ordinary re-saves destroy the credential. A JPEG quality change, a PNG re-save, a format conversion, a resize, and a screenshot of the image. Every marker gone, not degraded. The screenshot of the signed PNG came out the same size as the unsigned original, because a credential is not part of what a renderer renders. Absence is the overwhelming case and it means nothing at all. Anyone building a rule on "no manifest, therefore suspicious" is building a rule that fires on the entire honest internet.

Six of six tampers detected, with two distinct codes that a report must not conflate: assertion.dataHash.mismatch (the picture changed under a good claim) and claimSignature.mismatch (the claim bytes themselves changed).

What this cannot tell you

The limits belong up front, not in a footnote, so here are mine.

Every validation above is against a development certificate. No file signed by a real Anthropic chain exists in my corpus. "Claude" describes what generated the image, never what validated the signature.
Three survival paths are unmeasured, not zero: LibreOffice export, Word to PDF, and a WhatsApp round-trip. Not installed, or a manual phone step. If you have any of the three, that is a genuinely useful thing to run and post.
Four of the five surfaces Anthropic lists are untested. I checked one, Claude Code, where five of five generated images carried no manifest. The caveat that makes that honest: Claude Code has no image-generation model. It writes an SVG and drives your own C2PA-unaware local tools to rasterize it, so no signing step exists in that path. That is not "Anthropic failed to ship". It is what the support page's own hedge, "some platforms or features may not support certain marking types", costs a downstream verifier.
None of this says how often signed files arrive. Our standing baseline over real documents is 0 of 4,902 embedded images. This is early infrastructure, not a present-day signal.
One machine, one day, one Chrome build. A print pipeline with downsampling enabled, or Acrobat's "reduce file size", would each be a row I did not run.

What I would actually do with a suspicious document

Do not start with the prose. The text test is key-gated and the classifiers have the false-positive rates above. Notice you are holding a file.
Ask the file. A PDF is an append-only container that keeps receipts about its own history: revisions appended after creation, the producing toolchain, an Info dictionary and an XMP packet that stopped agreeing, whether a signature still covers what it signed, and printed totals that do or do not add up. None of that is about the writing, and all of it is deterministic. That is the AI-generated PDF guide.
Check provenance where it exists, and read absence as nothing. For images the AI-generated image guide covers what a valid manifest proves, what it never proves, and why absence is uninformative.
Never let one signal become a verdict. Signals about bytes are defensible. "Our system detected fraud" is the sentence that ends up in a complaint.

The full write-up of the nine PDFs, with the survival matrix and the reproduction steps, is on my site: A C2PA signature survives a PDF, and c2patool can't see it. There is a free checker on tamperlens.com if you want to drop a document in and see what its own bytes say. Nothing is stored.

If you run the LibreOffice, Word or WhatsApp path, I would genuinely like the result, including if it contradicts mine. And if you disagree with the framing that the text half is unusable today, the comments are the right place for it: that is the half I would most like to be wrong about.

The black box in your PDF is a shape, not a delete key

Haruo — Mon, 03 Aug 2026 15:44:04 +0000

There are two ways to black out a name in a PDF.

The first deletes the text and then draws a black rectangle where it used to be.
The second just draws the black rectangle.

On screen they are indistinguishable. In the file they are entirely different
documents, and in the second one every character of the name is still there —
selectable, copyable, and extractable by any PDF library in about one line of
code.

This mistake keeps reaching production in court filings, FOIA releases and
regulatory submissions, from organisations that employ lawyers and document
teams. It survives not because people are careless but because there is no
feedback: the person doing the redacting sees a black box either way, and
nothing tells them which one they made until somebody else selects the text.

A PDF page is a program

The reason the two operations look the same is worth understanding, because it
is also the reason you can tell them apart.

A page's content stream is a sequence of operators executed in order onto a blank
canvas. A very small one looks like this:

BT /F1 12 Tf 76 660 Td (Dana Whitfield) Tj ET
0 0 0 rg
74 656 120 16 re f

Reading it out: begin text, select font F1 at 12pt, move to (76, 660), show the
string Dana Whitfield, end text. Then set the non-stroking colour to black
(rg), build a rectangle at (74, 656) 120 wide and 16 high (re), and fill it
(f).

There is no z-index here, and no concept of one object being "above" another.
There is only order. Later paints over earlier. The rectangle covers the name for
the same reason a second coat of paint covers the first.

Now swap the two halves:

0 0 0 rg
74 656 120 16 re f
BT /F1 12 Tf 76 660 Td (Dana Whitfield) Tj ET

Same objects, same coordinates, opposite order — and now the name is drawn on
top of the black box and is perfectly legible. Which is exactly what a table's
shaded header row is: a filled rectangle, painted first, with text on it.

That single fact is the whole of what follows.

Check it yourself in one line

If you have a PDF with a black box in it:

pdftotext -layout suspect.pdf - | less

If the "redacted" words appear in that output, they were never removed. That is
the entire test, and it is worth running on anything you are about to send.

To look at the operators rather than the text, decompress the streams first —
content streams are Flate-compressed, so strings and grep see nothing useful
without this step:

qpdf --qdf --object-streams=disable suspect.pdf decompressed.pdf
grep -n --text -E ' (re|f|Tj|TJ)$' decompressed.pdf | head -40

Now you can read the page as the program it is, and see for yourself whether the
Tj comes before the re f.

Why "is there a dark rectangle near text" is the wrong check

The naive detector — find dark filled rectangles, find text underneath, report —
fires on an enormous number of completely honest documents. Every table with a
shaded header. Every highlighted paragraph. Every coloured callout box.

Paint order separates them cleanly, and it does so by construction rather than
by tuning: a background that was painted after its text would have hidden that
text, so it would not be a background. If you can read the text, the shape came
first. If a shape came second, it is hiding something.

Three more guards matter in practice, and each one exists because the version
without it produced false positives:

Transparency. A highlighter is a filled rectangle painted over text, and it
hides nothing. The graphics state carries a non-stroking alpha (ca, set through
a named ExtGState), so anything meaningfully translucent is ignored.

Size. A shape covering more than about 40% of the page is a watermark, a
stamp or a page background. Nobody redacts a name by covering half the page.

Invisible text. Rendering mode 3 (3 Tr) draws nothing. That is the OCR
layer underneath a scanned page — text that is designed to be invisible on
screen and extractable by machine. Reporting it as a failed redaction would fire
on every scanned document ever produced.

Getting the words back out is a separate problem

Finding that a run of text sits under a box tells you there is a leak. Saying
what leaked needs one more step, because the bytes inside a Tj string are
character codes, not characters, and what they mean depends on the font.

A font can carry a /ToUnicode CMap that maps them:

1 begincodespacerange
<00> <FF>
endcodespacerange
5 beginbfchar
<01> <0041>
<02> <0044>
<03> <004D>
<04> <0049>
<05> <004E>
endbfchar

With that, the content-stream bytes \001\002\003\004\005 — which are not text
in any useful sense — resolve to ADMIN.

Fonts without a /ToUnicode map are common, and there the honest answer is "the
coverage is real, the words could not be decoded here" rather than a guess.
Simple fonts usually turn out to be WinAnsi-encoded, where the byte is the
character, which covers most of the practical cases.

Things that are not redaction

All of these leave every character in the file:

Drawing a filled rectangle over the text.
Using a black highlighter annotation.
Setting the text colour to match the background.
Placing an image over the area.
Adding a /Redact annotation and not applying it. This one is the cruellest, because it is the right tool used incompletely — the annotation is a mark requesting redaction, the content only leaves when the tool applies the marks, and most viewers draw the pending marks as solid black boxes. The half-finished state looks exactly like the finished one.

What does work: your tool's redaction feature, followed by actually applying it.
Or exporting the page to a flattened image, which removes the text layer along
with your searchable text.

What this kind of check cannot see

Worth being explicit, because a checker that implies more coverage than it has is
worse than none:

Form XObjects. Reusable content blocks are their own little content streams. A covering box inside one is invisible unless you recurse into them, so any count is a floor rather than a total.
Already-flattened pages. No text layer, nothing to find — which also means the redaction worked.
Everything outside the page content. A name taken off the visible page can still be sitting in the document metadata, an attachment, a form field, or an earlier revision of the file. Different problem, different checks.

If you would rather not do it by hand

I built Tamperlens because I got tired of running the qpdf/pdftotext dance on documents people sent me and wondering whether I had missed one. Drop a PDF in and it walks each page's content stream tracking the transformation matrix, fill colour, alpha and paint order, computes boxes for the text runs, and reports the runs that ended up under
something opaque — with the recovered text, because if a checker can read it so can anyone who received the document. Nothing is stored: files are parsed in memory and discarded with the response.

There is a fictional sample on the page that opens automatically, so you can see
the output before deciding whether to trust it with anything of your own. It
contains a shaded table band with text on it as well as two real covers, so you
can watch the discrimination work in the same report.

The most useful four minutes you can spend with it: take any document, draw a
black rectangle over a line in whatever editor you have, export it, and check
that. Watching it recover the words from a file whose history you personally know
is worth more than this post.

What a forged bank statement looks like at the byte level

Haruo — Mon, 27 Jul 2026 17:49:36 +0000

I spent a chunk of my career in KYC/AML and document verification, mostly looking at things people had uploaded hoping nobody would look too closely — so this is the file format I have the most opinions about and the least affection for.

Here is the thing that took me embarrassingly long to internalise: a PDF is not a picture of a document. It is an append-only container with a linked list of revisions in it, and it keeps receipts about its own history whether or not anyone wanted it to. Most people editing a PDF have no idea that the thing they edited is still in the file.

Let me walk a constructed example. Imagine a bank statement, generated server-side, two pages, one credit line that says the account holder received rather less than they would like a lender to believe. They download it, drop it into a free browser-based PDF editor, white out the number, type a bigger one, hit download. Two minutes of work.

Here is what that leaves behind.

1. Count the ends of the file

$ grep -c '%%EOF' statement.pdf
2

A PDF ends with %%EOF. Ours contains two of them, and the second one is not a typo.

PDF supports incremental update: a conforming writer, instead of rewriting the file, may append new objects, append a new cross-reference section covering only what changed, append a new trailer, and append a new startxref / %%EOF. The original bytes are left exactly where they were. A document saved three times can physically contain all three states, and you can render any of them by truncating the file at the right offset.

This is a feature, not a bug — it is how digital signatures manage to preserve the bytes they signed. Which also means the count alone is weak evidence. Signing a document is an incremental update. So is filling in a form field, or adding an annotation. Linearised ("fast web view") files legitimately have two %%EOF markers from a single save, because the first-page cross-reference section sits near the front of the file with its own trailer.

So: interesting, not conclusive. Keep going.

$ grep -abo 'startxref' statement.pdf
118201:startxref
183640:startxref

2. Walk the /Prev chain

Every appended cross-reference section's trailer carries /Prev: the byte offset of the previous section. That is a backwards linked list. Enter it at the last startxref in the file and walk until a trailer has no /Prev; that terminal section is the original document.

Our tail:

trailer
<< /Size 41 /Root 1 0 R /Info 9 0 R
   /Prev 118201 /ID [<8f2c9a1b...> <41de77c0...>] >>
startxref
183640
%%EOF

Now read the appended cross-reference section that 183640 points at:

xref
0 1
0000000000 65535 f
12 1
0000119004 00000 n
trailer
<< ... /Prev 118201 ... >>

It lists exactly one live object: 12. And object 12 already existed in revision 1.

That is the whole finding. Object resolution in PDF always uses the newest section that mentions an object number, so whatever object 12 is now, it has replaced what object 12 used to be. Check what kind of object it is:

$ mutool show statement.pdf 12
<< /Length 2841 /Filter /FlateDecode >>

A content stream. On a page. That means what the document renders changed after it was generated — and revision 1 is still sitting in the file at offset 118201, so I can extract both and diff them.

This is the distinction I would put on a wall if I were running a document-review team: "the file has two revisions" is a medium-strength observation with a dozen innocent explanations. "A later revision replaces an object that already existed and that carries page or content-stream data" is a strong one, because there is no version of that sentence which is compatible with "the bank generated this and nobody touched it."

3. The /ID pair, which the spec maintains for you

Look again at that trailer:

/ID [<8f2c9a1b...> <41de77c0...>]

Two byte strings. The specification gives them different jobs: the first is a permanent identifier established when the document is created and must never change; the second is rewritten every time the file is written again. Two different values is the format's own record that this file was saved after it was created.

The original trailer, at offset 118201, has /ID [<8f2c9a1b...> <8f2c9a1b...>] — matching, as a freshly created file should. Watching element two drift while element one holds still across revisions is a satisfying little confirmation that you have read the chain correctly.

Its weakness matters as much as its strength: a tool that rewrites the whole file can set both elements to the same fresh value and erase the trace entirely. So divergence is informative; identity proves nothing. Almost every PDF signal is one-directional like this, which is why any honest tool in this space sells signals rather than verdicts.

4. Two metadata stores that stopped agreeing

Modern PDFs describe themselves twice: the trailer's /Info dictionary, and an XMP packet hanging off the document catalog's /Metadata key. XMP is RDF/XML and is conventionally stored unfiltered, which is why strings finds it when it finds nothing else.

$ strings statement.pdf | grep -A6 'x:xmpmeta'
<pdf:Producer>iText 7.2.5</pdf:Producer>
<xmp:CreateDate>2026-01-04T10:02:00+01:00</xmp:CreateDate>
<xmp:ModifyDate>2026-01-04T10:02:00+01:00</xmp:ModifyDate>

And the Info dictionary in the newest revision:

/Producer (iLovePDF)
/Creator (iText 7.2.5)
/CreationDate (D:20260104100200+01'00')
/ModDate (D:20260106184100+01'00')

Nothing in the format keeps those two in sync. Whether they agree is purely a property of the tools that touched the file, and plenty of editors rewrite the dictionary while leaving the XML alone because setting a dictionary value is much less work than rewriting XML.

Note precisely what happened here. The XMP packet still says the file was made by iText and never modified. The Info dictionary says iLovePDF and carries a /ModDate two days later. The divergence is the only reason the editor is visible at all. If you were only reading XMP — which is the modern store, and the one a lot of tooling prefers — you would see a clean file.

Multi-stage publishing pipelines produce plain divergence legitimately all the time, so a bare mismatch is a question rather than an answer. The narrow, strong version is this one: the two stores disagree about the tool, and only one of them names something whose purpose is editing.

5. The tell that survives metadata cleanup

Suppose our forger reads a post like this one and strips the metadata. Then this is still there:

$ strings statement.pdf | grep -o '/BaseFont *[^ /]*' | sort -u
/BaseFont /ABCDEF+Helvetica
/BaseFont /QWERTY+Helvetica

Embedded fonts are usually subsetted — only the glyphs the document actually uses — and the name gets a six-uppercase-letter prefix and a plus sign. The letters are arbitrary. What matters is that a generator writing a document in one pass collects every glyph it needs for a typeface into one subset with one tag.

Two tags for one typeface mean glyphs of that typeface were embedded on two separate occasions. That is the trace left when text is added to, or replaced in, an existing PDF by a different tool — and because it lives in the page resources rather than in metadata, it survives metadata stripping and it survives a whole-file rewrite that flattens the revision chain.

It is also the signal I have seen misread most often, so: merging two PDFs that both use Helvetica produces exactly this pattern, innocently. Someone combining two monthly statements into one upload will trip it. Never read it alone.

6. What a ByteRange gap actually proves

If the statement is digitally signed — routine in parts of the EU and LATAM — there is one more check, and it is the strongest structural finding available in the format because it is arithmetic.

A signature dictionary's /ByteRange is an array of offset/length pairs naming the bytes that were hashed, normally covering everything except the hole where the signature itself sits:

/ByteRange [0 8420 42840 15680]

covered through 42840 + 15680 = 58520
file length                   = 61204
                                ------
bytes outside the signature    =  2684

Those 2,684 bytes were appended after signing and are not protected by that signature. No certificate needed, no trust store, no crypto: you compare two integers. And it holds regardless of whether the signature validates, which is the part that catches people out. A viewer can correctly report a valid signature while displaying content the signature never covered — that is what "signed, with subsequent changes" means, and users click straight past it.

The honest caveat, because this one gets oversold: bytes outside the range are not automatically illegitimate. Multi-signature workflows produce them by construction, and PDF has a whole mechanism (DocMDP permissions) for declaring which subsequent changes the signer allowed. Reporting a coverage gap is not the same as deciding the change was forbidden.

The uncomfortable part

None of these signals is robust on its own, and I would distrust anyone who tells you otherwise.

Metadata cleanup is one line of code and kills signals 3 and 4.
A whole-file rewrite kills the revision chain and can erase the /ID divergence — but destroys any signature and leaves conspicuously fresh, coherent metadata.
Flattening the page to a raster image kills the font tell — and produces a document whose own shape (a full-page scan where a machine-generated statement should be vector text) is the finding.

The evasions are close to mutually exclusive. That is the actual reason a set of independent signals is worth having: not because any one of them is hard to defeat, but because defeating one tends to light up another.

It is also why I think the only defensible framing is signals, not verdicts. "This file contains two revisions, a later revision replaced a page content stream, and the Info dictionary names an online PDF editor that the XMP packet does not" is specific, true of the bytes, and something a human can act on. "Our system detected fraud" is neither of those things, and it is the sentence that ends up in a complaint.

If you want to skip the hex editor

I built Tamperlens because nothing self-serve existed between "read the bytes yourself" and "request a demo". It is a raw-byte parser — deliberately not built on a high-level PDF library, since those normalise away exactly the evidence described here — that runs eleven signal families and hands back JSON.

There is a free checker on the front page: drag a PDF in, get the report, nothing is stored. The most useful thing you can do with it takes about four minutes — put a statement you know is genuine through it, then run the same file through a free online PDF editor and put that through. Watching which signals light up on a file whose history you personally know is worth more than any blog post, including this one.

Every signal family, with its benign causes documented at the same length as its malicious ones, is in the field guide.

Happy to argue about any of this in the comments — particularly if you have a case where one of these signals fired on something entirely innocent, because those are the interesting ones.