Originally published at htpbe.tech. The version on htpbe.tech stays in sync with the latest detection algorithm — refer to it for the canonical text.
Every month we look at aggregate, anonymized data from the checks processed by HTPBE and write up what the structural signals say about the documents that reached us. No file contents, no personally identifiable information – only the structural and metadata patterns the algorithm uses to classify a file.
This report is about proportions, not raw counts: what share of processed checks came back flagged, how the confidence and origin mix broke down, and what the recurring tampering shapes looked like. A single month’s absolute file count is noise by comparison, so none appears here.
Read every figure below as a September snapshot. The months are not directly comparable – the composition of what reached the pipeline changed, and so did what becomes a stored row – so there is no month-over-month line to draw, and we draw none.
What the Denominator Is, Before Any Number
Every share below is a share of processed checks – completed analyses, not unique documents and not unique users. That denominator includes our own internal and automated runs, owner testing, fixture regressions, and retries; it is not deduped, and it excludes nothing. The same file submitted twice counts twice.
So this is not a population fraud rate, and no figure here should be read as one. It describes what reached our pipeline and how the pipeline classified it. Most of what reached us in September was anonymous web uploads and documents people already had reason to suspect, alongside our own internal testing – files pre-selected toward the interesting cases, which lifts the flagged share on its own and says nothing about how often documents in the world are altered.
HTPBE performs structural tamper detection. It reads how a PDF was built and rewritten; it does not verify identity, confirm an issuer’s records, or judge whether the content is true. Nothing here is a KYC or identity check, and a verdict is an input to review, not an adverse decision on its own.
The Shape of the Verdicts
Just over half of processed checks came back flagged as structurally modified in September. Read it as a September snapshot – a single-month figure, not a movement in either direction.
One thing shapes that top line, and the not-modified figure below it. From late September, checks that previously ended in an error now return an inconclusive result instead, and those checks enter these shares – a change noted in our public changelog. It means even the September snapshot is a blend: some of what the shares now count are checks that could not be completed in full, which are neither clean nor modified. This report does not split that blend out, so we flag it rather than quantify it.
The confidence tiers, as a September snapshot:
| Verdict tier | Share of September checks |
|---|---|
| Not returned as modified | just under half |
| Flagged – high confidence | about a third |
| Flagged – certain | about one in five |
That top row is not a clean-bill count. It bundles files returned as intact, files returned inconclusive – where the evidence is insufficient to rule modification in or out – and, from late September, checks that could not be completed in full. This report does not break them apart, so read the row as not returned as modified, never as confirmed fine.
A note on the lower two rows: certain describes how confidently the engine made the modification call. It is never certainty about intent, and never a fraud finding.
Source and Origin Mix
Two origin classes led the September snapshot. Consumer-software exports were the largest class, at just under half of processed checks, with institutional documents next, at about a third. Read those strictly as a September snapshot: an in-window reclassification moved files between origin buckets during the month, so the snapshot is itself a within-month blend. You can see the full aggregate breakdown on the PDF statistics page; the month figures here are directional against it.
A large consumer-software slice is easy to misread as a large suspicion signal. An inconclusive result is an honest limit on the evidence, not a red flag. When a file’s origin cannot be established firmly enough to support an intact-or-modified call, the engine returns inconclusive rather than forcing one.
On where submissions came from: in September, web and anonymous uploads made up the majority of processed checks, while checks arriving through the API path were a negligible share. The anonymous-upload segment is newly tracked, and September may be its first full month on record, so we read it as a snapshot and attach no cause or market signal to it.
Other Structural Signals
The reads that lean least on any single verdict are in the structural composition of what showed up.
About one in six processed checks were run on a file with no readable creation date. Treat that as approximate and as a September snapshot: the way this field is measured changed within the month, so the figure is a within-month blend rather than a stable count. It is a share of processed checks – shaped by the submission mix, internal and retry runs included – and it describes what the submitted files contained, not a claim about how many documents in the world lack a creation date.
We keep the thin slices qualitative. Signed documents, post-signature edits, signature removals, embedded files, and JavaScript were each too small a base in September to quote a rate, so we report no number for them. The one signed-document point worth repeating is the standing one, and it concerns the file’s history only, not the legal or issuer validity of a signature: a signature that displays as valid does not, on its own, show that a document is unchanged.
Incremental Updates
Incremental updates – content appended to a PDF after its original write – split into two numbers that should not be blurred.
Under one in ten of all processed checks were run on a file that carried incremental updates, as a September snapshot. The revision chains on those files were short – only a few post-write layers.
Among the checks run on files that carried incremental updates, nearly all came back flagged. Read that strictly as a September snapshot with a small base: it is not a trend claim in either direction. The mechanism itself is straightforward – incremental updates let content be added after the original write, and while legitimate workflows produce them (signature application, annotation, form-fill), those clean cases are a minority of the population that reaches a tamper-detection tool.
Representative Cases
These are composite, anonymized illustrations of the recurring shapes the engine resolved in September – not specific files. Each maps to the structural markers that drove the verdict, and each describes a modification – never proven fraud or intent.
The reconstructed statement (verdict: modified). A file reads as one coherent statement, but structurally its pages come from more than one source. It is reported as an assembled file, never as an untouched original.
The rebuilt document (verdict: modified). A file presented as an untouched institutional original has, structurally, the shape of a rebuilt file rather than one produced as the original – a rebuilt construction. The claim is about structural shape, not that a specific prior original was demonstrated.
The edit after signing (verdict: modified). A document was changed after it was signed, so it is reported as modified. Carrying a signature neither marks a document as modified nor clears it; the result reflects what the file’s history actually shows. A finding concerns the file’s history – not the validity of any signature or the identity of a signer.
The scan edited after capture (verdict: modified). A page with the structure of a scan, but whose embedded image shows signs of having been edited after capture, is reported as modified. Including scanned material is not by itself treated as evidence of an edit.
A result that is inconclusive, or a check that could not be completed in full, is not a clean result. Neither certifies an untouched original. It means the evidence was insufficient to rule modification in or out – nothing more, and nothing less.
Algorithm Development
Ten versions shipped in September. Described in outcome terms only:
- Corrections to cases where a document could be reported as modified, or carry a finding, without the evidence supporting it.
- Stricter handling of edits made after a document is signed.
- Some documents now return a different result in either direction – a genuine document can come back modified where an earlier release did not report it, as well as the reverse.
- Checks that previously ended in an error now return an inconclusive result instead – and, to be clear, an inconclusive result is not a clean result.
- Broader recognition of consumer-produced and print-to-PDF origins, which are no longer certified as untouched originals.
- A few public check descriptions made clearer, with no change to detection.
We are deliberately not drawing a line from this release mix to the flagged share. The in-window releases pushed in several directions at once, and their net is tangled up with the shift in what reached the pipeline. Comparability with August is limited, and that is the honest description of it.
PDF Version Landscape
As a September snapshot, PDF 1.7 was the most common version at about 37% of processed checks, with PDF 1.4 next at roughly 28%. The rest trailed, and PDF 2.0 was a rounding-error share despite years of availability. This is directional only – no significance test was run – and, like the missing-creation-date read, it is a detector-independent carrier: it reflects the submission mix, not real-world version adoption.
Summary
September 2026, in relative terms and read strictly as a snapshot:
- Just over half of processed checks came back flagged – a September snapshot, and from late September the figure also folds in checks that could not be completed in full.
- The confidence tiers broke down as roughly just under half not returned as modified, about a third flagged at high confidence, and about one in five flagged at the certain tier – a snapshot, with the top row bundling intact, inconclusive and incomplete checks.
- Consumer-software exports led the origin mix at just under half, with institutional documents next at about a third – a September snapshot shaped in part by an in-window reclassification.
- About one in six processed checks were run on a file with no readable creation date – approximate, because the way the field is measured changed within the month – and under one in ten on a file carrying incremental updates with short revision chains. Both are carrier reads shaped by the submission mix, not real-world change.
- PDF 1.7 was the most common version at about 37% – directional, a submission-mix carrier, not adoption.
- The months are not directly comparable: intake composition and within-month measurement and classification changes mean every figure above is a September snapshot.
Every pattern here comes from the same forensic engine that is available through the PDF tamper detection API. To run a single document through the same analysis by hand, use the free checker on the website.
Previous report: PDF Integrity Report: August 2026.
This report covers checks processed by HTPBE in September 2026. We analyze only file structure, never document content; web uploads may be retained in anonymized form to improve detection. All figures are aggregate and anonymized.
Top comments (0)