Tamperlens and HTPBE

How to read this page

Side by side

Where the two designs actually differ

Their own check count, on two of their own pages

Two figures for the same thing are published at once, and a reader comparing products should know which one they are being quoted:

• 63: "63 forensic checks across metadata, file structure, and digital signatures" on their home page, and "the same 63 forensic checks per file" on their pricing page (both read 2026-08-06).
• 35: "HTPBE's 35-check forensic analysis", in their own blog post on API pricing, published May 2026 (read 2026-08-06).

We have no way to tell which number is current or how either is counted, so we draw no conclusion from it. We note it because a check count is the kind of figure a comparison gets quoted on, and because we would want the same noted about us. For what it is worth, a count of checks is a poor unit anyway: it says how many things were looked for, not how often the answer was right.

Where HTPBE is the better answer

• The documents cannot leave your network. They sell an on-premise deployment and we do not sell one at any price.
• You want an engine that never reads the words. "Only the file structure" is a stronger promise than "read and discarded", and for some documents that difference is the whole decision.
• You need a handful of checks, once. Eight checks for $5, with no subscription, is a shape we do not sell.
• You need a stated response time. They publish one; we do not.

Where Tamperlens is the better answer

• Volume. At their Growth tier a document costs about ten times what it costs on Solo. The arithmetic is in the table and it is theirs, not ours.
• Redaction. Replaying paint order recovers the words underneath a black rectangle that carries no redaction annotation at all, the failure behind the published redaction leaks, and the case a structure-only checker cannot see. See /redaction-check.
• Instructions hidden in the document. Text positioned, coloured or layered so that a person does not read it but the model reading the file does.
• Brazil. CPF, CNPJ and boleto identifiers checked by arithmetic on the check digits, looking nothing up about anybody, with prices quoted in reais.
• Beyond PDF. Images and Office files go through the same endpoint.
• The file goes straight in. Their API takes a URL and fetches the document from it; ours takes the document. For a bank statement or a payslip, "make the file reachable at a link first" is an extra system in the data path. One more place the document exists, one more expiry to manage, one more log it appears in.

What we cannot do

• No on-premise build, and no customer-managed keys.
• Recall is unmeasured. We know how often we flag genuine documents. We do not know how often we catch real tampering.
• A document forged from scratch and never edited may carry no structural trace: the same limit HTPBE states about itself, and it is honest of them to state it.
• No identity proofing.

What none of us publishes

No vendor in the table above publishes a false-positive rate on legitimate documents: how often the system flags a genuine file. Declining to publish a detection rate, as both of us do, is the right instinct; it is not the same as publishing the number that tells a buyer what review will cost.

Ours is at /evidence, with the population it was measured on, the date, and the engine version that produced it. The other comparisons are at /alternatives.