PDF Integrity Report: October 2026
This article is a snapshot – content was accurate as of November 2026. The product evolves actively; specific counts, examples, and detection rules may have changed since publication – see the changelog for the current state.
Each month we take the aggregate, anonymized data from checks processed by HTPBE? and report what the structural signals say about the files that reached us. No document content and no personally identifiable information is published – only aggregate shares of structural and metadata characteristics of the submitted files.
Every figure below is a proportion. A single month’s absolute file count tells you more about who happened to be testing that month than about documents, so none appears here.
October has to be read on its own. Eleven algorithm versions were released during the month, and they moved verdicts in both directions. Results are stored as they were issued, so the month mixes results issued under more than one version. Across those releases, some checks that used to end in an error began to produce a stored result, and some files that used to produce a result began to end in an error with nothing stored. Origin classes were reclassified during the month, and the way some fields are recorded changed too. For those reasons October is not comparable to September, and no trend line is drawn.
What Is Being Counted
Every share in this report is a share of processed checks: completed analyses. A processed check is not a unique document and not a unique user. The count includes our own internal and automated runs, owner testing and retries. Nothing is deduped and nothing is excluded, so the same file submitted twice counts twice.
The files are also self-selected. People send a file to a tamper-detection tool when they have a reason to look at it, and our own testing leans towards the hard cases. Both lift the flagged share without saying anything about how often documents are altered in general. So none of these figures is a population fraud rate, and none should be quoted as one.
HTPBE? performs structural tamper detection. It does not verify identity, confirm a record with the issuer, or judge whether the content is true, and nothing here is a KYC check. A modified result describes the file’s history, not anyone’s intent. An intact result is not proof that a document is authentic. A result is one input to a review, not a decision on its own.
Verdicts and Confidence
With that denominator in mind: a little over half of processed checks in October were flagged as structurally modified.
| Verdict tier | Share of October processed checks |
|---|---|
| Not returned as modified | a little under half |
| Flagged – high confidence | about a third |
| Flagged – certain | about one in five |
The top row is not a count of clean files. It bundles checks returned as intact, checks returned as inconclusive, and inconclusive results from checks that could not be completed in full. The report does not separate them, so the row means not returned as modified and nothing more.
The two flagged rows describe how firmly the engine made the modification call. ‘Certain’ is the name of the highest of those confidence tiers. It is not a guarantee – false positives can occur – and it is not a statement about intent or a fraud finding.
Checks that could not be completed in full
A check that could not be completed in full is never returned as intact. Where the evidence supports it, it is returned as modified; otherwise it is returned as inconclusive with status_reason analysis_incomplete. That inconclusive result is not a clean result and is not, by itself, a sign of tampering. Some analyses that cannot be completed end in an error instead, with no result stored and nothing charged; an error certifies nothing about the document.
In October, such an incomplete result began to be charged like any other delivered result. These checks sit inside the shares above, so some of the October figures are a blend that includes them. We do not split the blend out, and we give no figure for it.
Incremental Updates
An incremental update is content appended to a PDF after its original write.
Just over one in ten processed checks were run on incremental-update files, and nearly all of those were flagged. The way this field is recorded changed during the month, so read the figure as a snapshot.
That second figure is easy to over-read. Legitimate workflows such as signing and form-filling also add updates to a file, so an incremental update on its own does not mean a file was tampered with. We do not attribute the high flagged share to a cause; it is a read of what was submitted.
Source and Origin
Where checks came from. Anonymous uploads made up roughly three in five processed checks and other web uploads about two in five.
How files were produced. Institutional and consumer-software origins each accounted for roughly a third of processed checks, about level with each other. Scans were about one in ten, and online editors a small share. The remainder could not be assigned a producer class.
These are structural producer classes. Institutional describes how a file was built – the kind of software and process behind it. It does not mean the file was issued by an institution, and it does not mean the file is authentic. A scan or a consumer-software origin is never presented as a certified original, and neither is, on its own, evidence of an edit.
Aggregate figures are also published on the PDF statistics page; the October figures in this report are a single-month snapshot on their own base.
Other Structural Reads
About one in five processed checks were run on a file with no readable creation date. This reflects what the submitted files carried, shaped by the submission mix, and the way the field is measured changed during the month. It is not a claim about how many documents in general lack a creation date.
Several slices were too small a base in October to quote a rate, so we give no number for them: signed documents, edits after signing, signature removals, JavaScript, and a few of the narrower origin classes.
PDF Version Landscape
PDF 1.7 accounted for about 40% of processed checks, and PDF 1.4 for about a fifth. Treat both as directional. No significance test was run, and the version mix reflects what was submitted, not how widely each version is used.
Representative Patterns
These are composite, anonymized illustrations of shapes the current engine reports. They are not specific files. Each describes a modification – never intent, and never proven fraud.
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. The claim is about that structural shape; it does not say a particular earlier original was shown to exist.
The edit after signing (verdict: modified). A document was changed after it was signed, so it is reported as modified. The finding concerns the file’s history only. It says nothing about the signature itself or about who signed.
The scan edited after capture (verdict: modified). A page built like a scan carries an embedded image that shows signs of editing after capture, and it is reported as modified. Scanned material on its own is not treated as evidence of an edit.
An inconclusive result, including one carrying analysis_incomplete, certifies no untouched original. It means the evidence did not settle the question either way.
Algorithm Development
Eleven versions were released in October. In outcome terms:
- Corrections in both directions. A document can come back modified where an earlier release did not report it that way, and the reverse; some can also come back inconclusive.
- Broader existing checks. Some documents an earlier release reported as intact or inconclusive can now come back modified; for those documents the result only becomes stricter.
- More robust handling of malformed files.
- An analysis that cannot be completed in full is never returned as intact, and some documents can now come back inconclusive as a result – see the section on checks that could not be completed in full.
- Billing aligned so that an incomplete result is charged like any other delivered result.
- Clearer public check descriptions, with no change to any result.
- One API error code changed: a timed-out analysis is now reported as
analysis_timeout. The changelog has the detail.
Results issued before a release are kept as issued and are not re-assessed, which is why the month mixes versions. We do not connect this release mix to the flagged share, and we make no claim that detection improved over the month.
Summary
October 2026, in proportions, to be read as a single-month snapshot of processed checks – not unique documents, and not a fraud rate:
- A little over half of processed checks were flagged as structurally modified. A little under half were not returned as modified, a row that bundles intact results, inconclusive results, and inconclusive results from checks that could not be completed in full.
- About a third were flagged at high confidence and about one in five at the certain tier – confidence in the modification call, not in intent.
- Just over one in ten were incremental-update files, nearly all of them flagged; legitimate workflows such as signing and form-filling produce incremental updates too.
- Institutional and consumer-software origins were roughly level at about a third each, scans about one in ten, online editors a small share.
- About one in five checks were on a file with no readable creation date; PDF 1.7 was about 40% and PDF 1.4 about a fifth. Both are reads of the submission mix.
The same structural analysis is available through the HTPBE? API. To check a single file by hand, upload it on the HTPBE? homepage. New accounts get 5 free credits on signup.
Previous report: PDF Integrity Report: September 2026.
This report covers checks processed by HTPBE? in October 2026. We analyze file structure and metadata and never read the substantive content of a document. Files uploaded through the website may be retained after analysis, kept without linkage to the uploader’s account, to test and improve detection; files submitted through the API are not stored. All figures are aggregate.