DEV Community: Haruo

Inscribe says AI is under 5% of document fraud, AppZen 70.8%. Both are right.

Haruo — Tue, 08 Sep 2026 15:50:26 +0000

Two companies that detect document fraud published numbers this year that
appear to contradict each other completely.

Inscribe (20 January 2026, 2026 State of Document Fraud Report):
AI-generated documents were less than 5% of the fraudulent documents it
flagged in lending during 2025. Their words: "the majority of document fraud
is still template-based."

AppZen (26 June 2026, via PYMNTS):
70.8% of flagged fraudulent expense receipts were AI-generated by mid-May
2026: up from 0% in March 2025. That's 1,471 AI-generated fake receipts,
submitted by 745 employees, at 174 companies.

Less than 5%. Or 70.8%. Pick your headline.

Both are right

The numbers measure different populations, and once you see the denominators
the contradiction disappears.

Inscribe's denominator is every fraudulent document flagged across its
lending customers: bank statements, pay stubs, tax forms, business filings.
That's a world where forgery already worked before generative models arrived.
Inscribe's own measure of it: template-based fraud was 1 in 5 flagged
documents in 2025, up from 1 in 14 in 2024. The usual explanation, which I
went looking for a primary source on and could not find, is that template
farms sell editable pay stubs and bank statements that look right because
they started from the real thing; the share is measured, the explanation is a
hypothesis. Either way, against that installed base, AI generation is a small
new entrant. If you're underwriting loans, most of the fake documents you'll
see this year are still edited or templated, not generated.

AppZen's denominator is flagged fraudulent receipts in expense reports.
A receipt is the easiest document in the world to generate: low resolution
expected, no issuer database to cross-check, thousands of legitimate layout
variations. The base rate of sophisticated receipt forgery was always near
zero, because nobody needed sophistication to fake a $40 dinner. When image
models made generation free, it took over that category almost instantly, 0%
to 70.8% in fourteen months.

Same industry. Different documents, different fraud economics, different
numbers. Anyone quoting either figure without its denominator is misleading
you, and both figures are being recirculated stripped of exactly that
context. "71% of expense fraud is AI-generated" is already travelling through
AI-written content farms; it isn't what AppZen measured (70.8% of flagged
fraudulent receipts, not of expense fraud, not of receipts).

The number that should actually worry you

Here's the finding that doesn't depend on any vendor's platform data, from
AIForge-Doc (arXiv 2602.20569), an
academic benchmark of tampering detectors against AI-inpainted documents:

DocTamper, a specialised detector, scores 0.563 AUC out of distribution, against 0.98 in-distribution. Trained defenses collapse on fakes they weren't trained on.
TruFor: 0.751, against 0.96 in-distribution.
GPT-4o as a detector: 0.509, a coin flip.

The detectors built for the previous era score at chance on the new one.
That is independently measured, it is not marketing, and it's the reason we
treat every vendor detection-rate claim (including any we might be tempted
to publish ourselves) as unverifiable until someone shows a methodology.

What this means if you handle documents

Ask for denominators. "X% of fraud is AI" means nothing until you know fraud of what, flagged by whom, out of what population.
Match the defense to the document. Expense receipts and bank statements are different threat models. One is being flooded by generation; the other is still dominated by editing and templates, which leave structural traces (revisions appended after creation, producer strings that changed, metadata that disagrees with itself) that don't depend on how the visual layer was made.
Distrust round detection rates. Nobody in this market publishes a false-positive rate on legitimate documents. We publish ours, measured on uncurated public document populations, engine-version-stamped: tamperlens.com/evidence. We'd genuinely like not to be the only ones.

Tamperlens reads document structure and returns fraud signals as evidence, never an approve/deny verdict. Free checker, no signup:
tamperlens.com.

Our status page froze for four days because the CI minutes ran out

Haruo — Tue, 08 Sep 2026 15:48:23 +0000

On 19 August our GitHub Actions hosted-minutes quota ran out.

Everything you would expect to break broke, loudly, and was fixed inside two days. The thing that broke quietly was the uptime probe, which ran on a schedule on those same hosted runners. Every scheduled run since then died in about three seconds with no runner and no logs. By the time anyone looked, that was 165 consecutive failures.

Two consequences, and the second is the one worth the post.

The status page froze. status.tamperlens.com still said "Last checked" on 19 August at 17:13 UTC. Four days later it still said it. A frozen status page does not look broken. It looks like a service that is fine and nobody has poked recently, which is a strictly worse failure than a page that is down.

The probe was also the alarm. A failing run emailed the operator. Once the runs stopped starting, nothing was checking the API at all, so if production had gone down, nothing would have told anyone. That is the more urgent half, and it is the half that a "status page frozen" ticket does not describe.

The obvious fix does not work here

We already had a self-hosted runner on the production box, and the two workflows that mattered moved onto it two days later.

The uptime probe could not follow, for a reason that is not about our setup: that runner is the box being watched. A machine cannot meaningfully report its own outage. Worse, the status page's own copy makes the claim that it is probed from outside our network and served from outside it too, so it stays up when we do not. Moving the probe onto the box would have made the page lie rather than fixed it.

That constraint is the whole design. A status page is only worth having if the thing that measures and the thing that serves are both independent of the thing being measured. Ours had one of those properties (the page was served elsewhere) and had been getting the other from a CI provider, for free, as a side effect.

Which is the general lesson, and it applies well beyond monitoring: if a property of your system is a side effect of somebody's free tier, you have not designed for it, you have been lent it.

The move: a Worker with a cron

The probe now lives in a Cloudflare Worker with a scheduled trigger, writing history to KV. Cloudflare's edge is neither the box being watched nor the CI that deploys it, so the premise survives.

Two decisions inside that are more interesting than the migration itself.

The renderer did not move. The page is rendered by a module both the Worker and the existing Node CLI import, so the served page cannot drift from the one the CLI produces out of the same history. Migrating a monitor is a great way to end up with two subtly different renderings of the same data, and the fix is boring: extract the pure part first, make it depend on no filesystem, no clock and no process, and have both callers import it.

History moved from an orphan git branch to KV, and the reason is credentials. The old design kept history.json on an orphan branch, which was auditable and cheap to clone. A Worker cannot push to git without carrying a token that can write to the repository, and a monitor holding repo-write credentials is a worse trade than losing the git audit trail. The raw data stays public and one fetch away at /history.json, served from KV instead of GitHub.

The thing you are tempted to preserve during a migration is usually the thing whose cost you have not re-priced. A write credential in a component whose only job is to read is worth more to an attacker than the audit trail is worth to you.

What got worse, said out loud

The Worker's checker component is weaker than the Node probe it replaces, and that belongs in the post rather than in a footnote.

The Node probe fetches every script the page loads, parses each one, requires something to assign the bootstrap globals, and then executes them against a DOM and requires the demo report to actually render, plus a leg that drives a fixture PDF through a live POST /api/v1/inspect. A Worker has no DOM and no eval, so it stops after the parse-and-assign layer.

That layer is not the consolation prize, and here is why.

On 4 August a syntax error in one client script left every checker page dead for two days, while the origin kept answering 200 for the HTML. Four probes were green throughout, correctly: they asserted one HTTP status on one HTML document. One of them was even labelled "Website and free checker". A page whose scripts do not parse returns that status perfectly happily.

The monitor was watching the wrapper.

So the component that came out of that outage does something narrower and much more useful. It fetches the page, reads the <script src> list out of the HTML the origin actually served rather than from a hardcoded list, fetches every one, asserts each parses, and asserts that the bootstrap globals are assigned somewhere across them.

That last word is doing real work. const T = window.Tamperlens is a read, and it does not count. Every consumer script contains a line like it, so counting reads would make the check pass on exactly the day the file that does the assigning stopped loading.

The parse-and-assign layer is the layer that failed in the real outage. Losing the DOM execution on top of it costs something. Losing the layer underneath would have cost the only outage this component has ever had to catch.

The deeper probe did not get deleted, either. It kept a manual trigger and still runs the whole thing on the self-hosted runner on request, for use before a release or when the cheap probe says the checker is down and you want to know how far the damage goes.

The test that keeps two vantage points honest

There are now two implementations of "does this script parse": node:vm in the CLI, and a parser bundled into the Worker, because Workers have no vm.

Two parsers means two opinions, and two opinions about the same file means the repo and the edge can report different verdicts about it. So the load-bearing test in the Worker suite asserts that the two agree on what parses, including the exact historical breakage that caused the two-day outage.

That is the shape I would reuse anywhere a check gets reimplemented for a second runtime: do not test the new implementation against your expectations, test it against the old implementation, on the input that made you write the check in the first place.

The part the move did not fix, for one more day

The Worker as first deployed logged a failing probe with console.error, which reaches wrangler tail and the Workers logs, and nothing else. The old workflow at least emailed somebody when it failed. So for a day the move had restored the page and not the alarm, and that deserves saying out loud: the four-day outage above was invisible precisely because nobody was watching the watcher, and a fix that left that property intact would have been the same mistake with newer infrastructure.

I had two Cloudflare routes in mind for closing it and both were wrong for the job. Workers alerts fire on invocation errors, and a failing probe is not one: the Worker ran perfectly, the site did not, so console.error never trips it. Logpush is an Enterprise feature, which is why the menu item could not be found.

What got wired instead, on 25 August, is the dead man's switch we already run for the nightly backup and for the box's own guard script. The cron pings a healthchecks.io check when everything is up, pings its /fail URL with the failing component names when something is down, and, the part neither Cloudflare option offered, alerts by silence if the Worker itself stops firing. That last one is the exact failure mode that produced this post. The ping URL is a secret, and with it unset the Worker behaves as before, so it was safe to deploy before the check existed.

Where this landed

On 23 August the code was done and the cutover was not: creating the KV namespace, deploying, watching one real probe land, moving the custom domain off the old project. Five dashboard steps and one CLI call, which needed credentials and a DNS change that code cannot do for itself.

They happened that night. The first probe landed at 23:07 UTC with all five components up, on the same quarter-hour cadence the old workflow had asked for, and the four probes that ran before midnight all came back clean. status.tamperlens.com moved onto the Worker route at about 02:30 UTC on 24 August, and the "Last checked" line has read a timestamp from the last fifteen minutes ever since. It has also recorded a handful of short timeouts on its own since then, which is the page doing the thing the frozen one could not.

I wrote most of this before any of that, and I am posting it with the ending attached rather than rewriting it as a migration story, because "we migrated our status page" is a much less useful post than "our status page was frozen for four days and here is the whole reason it could be".

The four things I would check on your own setup

Is your probe also your alarm? If the same job both measures and notifies, its failure is silent by construction.
Does anything watch the watcher? A dead man's switch that expects a regular ping is a few lines and would have caught this on day one. Ours has one now, and it took the whole episode to get it.
Is your monitor asserting on the wrapper? An HTTP 200 on an HTML document says nothing about whether the page works. Assert on the thing that actually broke last time.
Which of your invariants are on loan? Independence, retention, alerting: if the property comes from someone else's free tier, write down what happens when the tier ends. Ours ended on a Wednesday.

What our monitoring commits to, what it deliberately does not, and the limits the status page states about its own measurement are on the security page. The product it watches is a document trust API: drop a PDF into the free checker and it returns the structural findings with the evidence under each one, no account, nothing stored.

If you have a monitor that stayed green through a real outage, I would like to hear which layer it was asserting on. Mine was asserting on the wrapper for months.

Six commands that beat my own PDF fraud detector, ranked by how well

Haruo — Tue, 08 Sep 2026 15:44:11 +0000

Every vendor in this space publishes what it catches. I have not found one that publishes what makes it stop working. So here is that second list for my own engine, measured rather than reasoned about.

The engine reads PDF structure and returns fraud signals. Nineteen families run on every document; a twentieth, issuer-mismatch, only fires when the caller supplies a baseline, so a bench that inspects a file on its own can never reach it. The six evasions below are one command each, they are all on the first page of results for "how to remove pdf metadata", and anybody selling forged statements already owns them.

The run: 98 PDF fixtures, engine 1.37.0, qpdf 12.4.0, exiftool 13.55, Ghostscript 10.07.1, and a Quartz CGPDFContext print path. One script, checked in:

npx tsx scripts/evasion-bench.mjs --in test/fixtures

The ranking, with the column that decides whether anyone does it

A family counts as silenced when every firing the bench could measure went quiet.

Evasion	families silenced, of 19	what it costs the sender
`exiftool -all=`	2	nothing, and it appends a revision
`qpdf --linearize`	1	any signature
print-to-PDF	9	the whole revision history
`gs -sDEVICE=pdfwrite`	11	any signature
`qpdf --encrypt`	13	nothing
`gs -sDEVICE=pdfimage24`	18	the text layer

The right-hand column is the one that matters and it is the one nobody prints. An evasion that costs the sender something is an evasion most senders will not use. Flattening every page to an image is the strongest move on the board and I have nothing that beats it, but it also breaks every downstream pipeline that reads text: no selection, no copy-paste, no extraction, no screen reader. Income parsers and accounting imports fail on arrival, before anyone reaches the question of whether the document is real.

Encryption is the interesting row, because it silences thirteen and costs nothing. An owner password does not stop anyone opening the file.

Four results I did not expect

1. A metadata strip makes four families louder

exiftool -all= on a PDF is not a delete. It is an append: a new revision in which the metadata is blank, with the original bytes left exactly where they were. So:

incremental-updates goes from one revision to two, which is the thing it looks for.
On a signed document the appended region sits past the end of the signed /ByteRange, which is the highest-severity finding the engine has.
id-inconsistency fires on a file that had nothing to say before. The appended trailer keeps the original /ID[0] and writes a fresh /ID[1], so a file whose two halves matched comes out with two that do not. The strip manufactures the finding it was run to remove.
font-anomalies reads info on a one-save file and worse on an edited one, so it went info to high on five of the six fixtures it fires on. Nothing about the fonts changed. The file simply stopped being a one-save document.

Tidying a PDF before sending it makes the report worse, not better. That is not clever detection. That is the file format.

2. "Whole-file rewrite" is not one column

qpdf and Ghostscript are both described as whole-file rewriters, and they disagree on fifteen of the nineteen rows. qpdf silences one family. Ghostscript silences eleven.

The mechanism is the difference between copying and re-rendering. A structural rewriter copies through what it does not need to understand: the Info dictionary, the XMP packet, the font objects. A re-renderer regenerates all of it from what it drew. So Ghostscript rewrites /Producer and copies /Creator through verbatim, meaning an editor that named itself in both survives a full re-render. It re-subsets fonts without merging them, so two subsets of one typeface stay two subsets. And it does not remove active content so much as move it: an /OpenAction came out the far side as an /A action on the catalog, which satisfies anyone grepping for the old key.

There is no answer to "what does a whole-file rewrite do to my signals" that does not name the tool.

3. Destroying a signature is quieter than invalidating it

Read the three signature-* rows across instead of down and the usual direction reverses.

Of nine signed fixtures that read above low as built:

the four evasions that keep the signature object (strip, qpdf rewrite, encrypt, and the two-step below) launder 0 of 9. A qpdf rewrite takes signature-coverage to high on all thirteen signed fixtures, because invalidating a signature is the loudest thing this engine reports.
the three that re-render the page (Ghostscript, print-to-PDF, raster) launder 9 of 9. All three signature families go quiet, because the signature does not survive rendering at all.

Which exposes the largest hole in my own engine, and it is worth stating plainly: there is no signal for "this document should carry a signature and carries none." An invalidated signature is a finding. An absent one is an ordinary PDF, and most PDFs are unsigned. So against a signed document the forger's answer is not to compose evasions harder, it is to print.

4. Printing from Chrome trips nothing, and that is deliberate

The consumer-editor list the engine matches producer strings against has around fifty entries. Quartz PDFContext is on it. Microsoft Print to PDF is on it. Skia/PDF, which is what Chrome writes when you print a page, is not.

I know how to close that and I am not going to. When we parsed 213 PDFs published by US banks, two Bank of America online-banking agreements came back as Skia/PDF m130 and Skia/PDF m135: printed straight out of a browser by whoever maintained the page. Adding Skia to that list turns a real bank's real document into a finding.

So printing from Chrome is the cheapest evasion in the table. It costs one keystroke and my engine says nothing about the tool that did it. That is a false-positive rate I chose to pay for in recall, and I would rather write the sentence than have someone discover it.

The column a forger actually runs

Every column above is one command, which answers the wrong question. Forgers compose. One pair composes into something neither half is:

exiftool -all= in.pdf
qpdf --linearize in.pdf out.pdf

The strip appends a revision and leaves the freed metadata objects in the byte stream, which is why its column reads "louder". The rewrite re-serialises from the object graph, dropping unreferenced objects and the revision chain, but on its own it carries the metadata disagreements through. Composed, the rewrite erases the revision the strip manufactured and the strip empties the stores the rewrite would have preserved.

This is not hypothetical. guillaumemeyer/watermarks-remover, an MIT-licensed tool for removing AI provenance marks, ships exactly this pair behind one command, in a Docker image, with a README, and warns in its own source that exiftool alone leaves "the original metadata bytes recoverable".

What it does to one document, in four states. This is a fictional proof of address whose page content was replaced after generation, and its clean twin:

File	Score	What the report says
clean, untouched	`0 low`	no signals at all
forged, untouched	`70 high`	`incremental-updates`: page content replaced after generation
forged, strip only	`100 high`	the above, plus the two the strip manufactured
forged, strip then rewrite	`10 low`	`producer-fingerprint` low, `id-inconsistency` info
clean, strip then rewrite	`10 low`	the same two, identically

On an unsigned document the two-step takes a real forgery from high to low, and the laundered forgery is indistinguishable from the laundered clean file.

It is also not the best evasion available, which I got wrong for about an hour on the day I first measured it. Over the 35 unsigned fixtures that read above low as built: a raster flatten launders 34, qpdf --encrypt 32, a Ghostscript rewrite 24, print-to-PDF 18, the two-step 13, qpdf --linearize alone 11, and exiftool -all= alone 0. Fifth of seven. What stands is the mechanism, and the fact that it beats either half alone.

Three things it cannot do, and they are why this is not a rout:

It does not produce an untouched-looking file. Both laundered files land on the same two residual signals. A PDF that declares no producing tool and has mismatched /ID halves has been through a rewriter. For document classes where the issuer always names its software, and statement and payroll pipelines do, "declares no producing tool" is the anomaly rather than the absence of one.
It is catastrophic on anything signed. All 13 signed fixtures came out high, including one that reads 0 low untouched.
It does not touch the page. The text under the black box is still there, the balance column still fails to add up, the check digit is still wrong.

The bench was counting its own failures as results

The part of this work I would most like other people to check their own harness for. It came out of the first time the checked-in bench was re-run, on 24 August, over the 92 fixtures the repository had that day.

Nine of those 92 are things a tool can legitimately refuse: one is not a PDF at all, one is already encrypted and cannot be re-encrypted, and Quartz will not open six files whose whole purpose is to be malformed. When a derivation failed there was no report to read, the summary read families?.[family] as undefined, and verdict(before, undefined) returned gone.

So a failed tool run was published as a silenced signal family. Nine cells were inflated by it. One cell, document-injection-markers under print-to-PDF, was published as gone on the strength of a single fixture Quartz refuses to open, which means that cell never had a measurement in it at all. It reads unmeasured now.

The irony is that the script already carried the rule it was breaking. Its own header says a variant whose tool is missing is UNMEASURED, "absent, not zero", because "a silently missing column is how a matrix starts lying". It enforced that per column and not per file.

Two general shapes fall out of that, and neither is about PDFs:

An absent measurement and a negative measurement must not share a representation. undefined flowing into a comparison that returns a meaningful verdict is the whole bug, in one line.
A rule enforced at the wrong granularity reads as a rule enforced. Nobody re-reads a guard that is present.

The engine, for what it is worth, is not responsible for any of it: running the whole bench on every build from 1.29.0 to 1.32.0 over the same fixtures produces byte-identical tables.

What I take from the table

Nothing in the unconditional set survives all six. Every one of the nineteen has at least one column in which every firing the bench could measure went quiet. The one family that never goes quiet is issuer-mismatch, and it is the one the bench cannot draw, because it compares the file to documents from the institution it claims to come from rather than reading the file's own account of itself.

That is the asymmetry in one sentence: self-description is defeated by regeneration, and comparison to an outside reference is not. The price is that you have to hold the reference.

And the operational reading, if you are the one receiving documents: a clean structural report means the bytes are clean. It does not mean the document is genuine. Those are different claims and the entire risk lives in the gap between them. Which is also why I think the only defensible output is signals rather than 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 a statement about bytes. "Our system detected fraud" is a statement about a person, and a parser does not get to make it.

The full matrix, cell by cell, with the three dated passes of corrections to the cells I got wrong, is at what defeats every signal. There is a free checker at tamperlens.com if you want to drop a document in and read its own report. Nothing is stored, and no account is involved.

If you run one of these evasions against a document you personally know the history of and get a result that contradicts mine, that is the comment I most want.

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.