How should I interpret PDF analysis results?

Every HTPBE? result is one of three verdicts – Intact, Modified or Inconclusive – and each one tells you something different about what to do next. The verdict describes the PDF file, not the person who sent it and not the truth of what the document says. There is no numeric score: you get a verdict, a confidence level on Modified results, and a list of named findings.

The three verdicts

Intact

No structural evidence of modification was found, and the file did not come from a source where an integrity check cannot apply (consumer software, an online editor, a scan). The file looks the way a document looks when it leaves the system that generated it.

What to do: carry on with your normal process. Intact is a good sign, not a guarantee – see ‘What a verdict does not tell you’ below.

Modified

The analysis found evidence that the file was changed after it was created. A Modified result is the only verdict that comes with a confidence level:

• Certain – the strongest level of evidence the analysis reports, such as dates recorded in the file that contradict each other (HTPBE_DATES_DISAGREE), content changed after a digital signature was applied (HTPBE_POST_SIGNATURE_EDIT), or a signature that was stripped after signing (HTPBE_SIGNATURE_REMOVED).
• High – strong forensic evidence, for example multiple revision layers (HTPBE_MULTIPLE_REVISION_LAYERS) or fingerprints of a known PDF editing tool (HTPBE_EDITING_TOOL_FINGERPRINT). Highly reliable, but rare false positives are possible in unusual legitimate workflows, so a person should look at the case.

What to do: do not accept the file on the strength of its appearance, and do not reject the person automatically either. Open the findings, check whether they fit the document’s known history (a re-save, a signing step, a format conversion), and where it matters, ask the issuer for a fresh copy straight from their own system. For a Certain result, treat the file as modified and take that route.

Inconclusive

The file was produced in a way that anyone can reproduce, so a structural check has nothing reliable to compare it against. This is not a failure and not a pass. The result page and the API (status_reason) state the reason:

• created in software that anyone can use;
• processed through an online PDF editor or converter;
• a scan of a paper document;
• a file whose history after creation could not be established;
• a completed form or a signing-app overlay.

What to do: route by the reason. If the document claims to come from a bank, an employer or another institution, a file made this way is itself worth a closer look, because those organisations do not normally distribute documents like this. Confirm the content with the issuer, or ask for the original export. The related question Why does my official document show INCONCLUSIVE? covers the genuine-document case in detail.

Inconclusive: the reason decides the action

The API returns the reason as status_reason. Each value points to a different next step:

• consumer_software_origin and online_editor_origin: anyone can create or reprocess such a file. Confirm with the issuer, or ask for the original export.
• scanned_document: a picture of paper. Ask for the original digital file.
• filled_form_origin and fill_sign_origin: a completed form or a signing-app overlay. Ask for the issuer’s own copy.
• visible_signature_origin: a visible signature that the check cannot confirm as unchanged. This is not a statement about whether the signature is valid; the signer’s certificate is never tested.
• unverifiable_metadata: the file’s history after creation could not be established. Not an edit finding, and not a clean bill.
• analysis_incomplete: the check could not be completed in full. Treat the document as unverified.

Three results, read in practice

• Modified, High, one finding about a re-save by another tool. The sender probably opened and saved the file. Ask for the portal download; if it is Intact, the earlier copy picked up its history on the way.
• Modified, Certain, content changed after signing. Do not accept the file. The signature no longer covers what is on the page.
• Inconclusive, online editor. Not an accusation. Ask where the original is and why this version was produced.

Routing results in a team

A simple scheme: Intact goes forward; Modified goes to a reviewer with the finding names attached; Inconclusive goes to a request-from-issuer queue, split by status_reason. The usage_caution block in every API result encodes the same routing and states that the verdict must not be used alone to reject a person. An outdated result (older algorithm version) carries an outdated_warning; run it again before relying on it for a new decision.

Reading the named findings

Findings are returned as public identifiers that start with HTPBE_ and each one has a plain-language description of the outcome it reports, for example ‘content changed after the document was digitally signed’ or ‘document re-saved by another tool after its original creation’. The identifiers never change once published, so you can safely key your own handling on them. Read them in this order:

• Start with the verdict and, on Modified, the confidence level.
• Read the finding descriptions to see what kind of change was seen: a date or metadata conflict, a signature problem, a revision history, a mismatch between the declared software and the file itself, or an edit inside the page content.
• Compare that with what you know about the document. A single finding that matches a legitimate step (the sender re-saved the file, a signature was added, the file was converted) reads very differently from several unrelated findings pointing at one page.

Alongside the verdict you also see the file’s metadata (creation and modification dates, creator, producer). It is context for the findings, not a verdict of its own.

What a verdict does not tell you

• Intact is not authentic. A document written from scratch with false data and never edited afterwards can still be Intact. HTPBE? detects modification of the file, not falsehood in what it says. See Can someone create a fake document from scratch?
• Modified is not fraud. It states a fact about the file, not intent. Plenty of honest workflows change a file after creation. See Why does my PDF show as modified even though I didn’t edit it? for the ordinary causes.
• Inconclusive is not suspicious by default. It says the check does not apply to this kind of file.
• There is no risk score. Do not look for a number or a percentage; the confidence level on Modified is the only graded signal.
• No result is a sole basis for an automatic decision against a person. Every API result carries a usage_caution block that routes Modified to human review, Inconclusive to the issuer and Intact to no action, and it always states that the verdict must not be used alone to reject an applicant, claimant or customer.

If the result looks wrong

Check the file’s own history first: who created it, in what tool, and whether anyone re-saved, signed or converted it afterwards. If you can obtain the original export from the issuing system, check that one, since it is the best reference you can have. Results also carry the algorithm version they were produced with, and an older result is flagged so you can re-run the file against the current version.

Using results in a workflow

For one-off checks, the result page is enough. For a process that handles many documents – lending, onboarding, claims, accounts payable – the same verdict, confidence level and finding identifiers come back from the HTPBE? API, so you can route Intact, Modified and Inconclusive files to different queues. Pricing is on the pricing page. To see what the analysis covers in more depth, read about PDF tamper detection and how to check if a PDF was edited.

Related questions

• Why does my official document show Inconclusive?
• What does the API response look like?
• Can HTPBE? tell a harmless re-save from a content change?