PDF Font Subset Divergence: Forensic Tampering Detection

Inside every PDF that embeds fonts is a six-character prefix that most people never notice. It is a small, public part of the PDF format – and a good way into a bigger question: whether a document’s pages all came from where the document claims.

Page assembly – combining pages from more than one source into a single file – is one of the most common ways a document is altered. It leaves structural traces in the file itself, and HTPBE? can surface them without a reference copy.

What font subsetting is

PDF renderers do not embed the full font file for every typeface they use. Embedding a full font – even a modest one – adds hundreds of kilobytes to a file for no practical benefit when only a fraction of its glyphs appear in the document. Instead, the renderer embeds a subset: only the glyphs the document actually uses.

The PDF specification requires that embedded font subsets be tagged with a six-character random uppercase prefix, followed by a + and the font name:

ABCDEF+Arial
XKZWQP+TimesNewRoman
MJVHRT+SourceSansPro

The forensic signal

When a document’s pages were produced separately and then combined, the file does not always line up with the way the document claims to have been made. HTPBE? treats that mismatch as evidence of page assembly.

Three concrete scenarios produce this pattern:

Multi-call document generation. Some automated pipelines build a PDF one page at a time, each page in a separate request, and then stitch the pages together. The result is an assembled document, even when every page came from the same service.

Page insertion from a foreign source. A common fraud pattern in document tampering is inserting a page from one PDF into another. A bank statement with a page replaced from a different statement, or a contract with a signature page substituted. The inserted page was produced somewhere else, and the file still carries evidence of that.

Template reuse. Some assembly tools build a PDF by combining pages from a template file with newly added pages. The finished file reflects that it was put together from more than one source.

What this exposes in practice

Page-assembly evidence is most relevant for two categories of documents.

The first is automatically generated financial summaries and reports. Some pipelines that produce statements, summaries or reports programmatically build them page by page. When a received document presents itself as a system-generated statement but shows signs of page assembly, its structure does not match the origin it claims. That does not prove fraud – it marks a document that warrants a closer look.

The second is manually assembled multi-source documents. HR and lending workflows regularly encounter documents where an applicant has taken pages from different source documents and combined them into a single PDF. A pay stub with a page from a different employer’s statement; a lease agreement with a different tenant’s financial page inserted. HTPBE? flags such a file as assembled from more than one source.

How HTPBE? surfaces this

When HTPBE? finds that a document’s pages were assembled from independently rendered sources, the analysis adds a modification marker to the result.

A response for a document whose pages were assembled from more than one source looks like this:

{
  "id": "ck_7e3b1a9d-4f2c-4d8a-c3e1-5b9f2a0e7d4c",
  "status": "modified",
  "modification_confidence": "high",
  "modification_markers": ["HTPBE_PAGES_FROM_MULTIPLE_SOURCES", "HTPBE_MULTIPLE_REVISION_LAYERS"],
  "xref_count": 2,
  "has_digital_signature": false,
  "creator": "Adobe Acrobat",
  "producer": "Adobe Acrobat",
  "creation_date": 1746057600,
  "modification_date": 1747872000,
  "page_count": 4
}

The HTPBE_PAGES_FROM_MULTIPLE_SOURCES marker means the document’s pages were assembled from independently rendered sources. Together with HTPBE_MULTIPLE_REVISION_LAYERS, which means the document was modified after it was created, this result is consistent with pages being inserted after the original was produced.

To submit a document for analysis:

curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-storage.example.com/submissions/application-pack.pdf"}'

Retrieve the result:

curl https://api.htpbe.tech/v1/result/ck_7e3b1a9d-4f2c-4d8a-c3e1-5b9f2a0e7d4c \
  -H "Authorization: Bearer YOUR_API_KEY"

The full result object includes page count, xref structure, digital signature state, and the complete modification_markers array. Marker descriptions are stable strings – safe to store and use in downstream routing logic.

Limitations

A page-assembly finding is not a certain-confidence marker. It is high confidence: a strong structural signal, but not cryptographically provable in the way that signature tampering is.

Several legitimate production workflows produce the same structural pattern:

Document assembly pipelines. Enterprise content management systems sometimes compose final PDFs from independently rendered components – a cover page from one service, body pages from another, appendices from a third. This is architecturally legitimate and produces the same structural pattern as page insertion fraud.

Print-and-scan-and-append workflows. Some legal and compliance workflows scan physical pages and append them to electronically generated PDFs. Files like these are assembled by design, so an assembly finding on them calls for a look at the workflow rather than an assumption of fraud.

Archival conversion. Some archival and compliance tools rebuild parts of a document during conversion. Depending on the tool, a legitimate document can come out of that process looking assembled.

When HTPBE_PAGES_FROM_MULTIPLE_SOURCES appears together with other markers, the overall picture is stronger than any single marker gives. When it is the only marker, treat it as a reason to look closer, not as grounds for automatic rejection.

Integrating page-assembly findings into document workflows

For backend workflows that need to handle this marker explicitly:

interface HTPBEResult {
  id: string;
  status: 'intact' | 'modified' | 'inconclusive';
  modification_confidence: 'certain' | 'high' | 'none' | null;
  modification_markers: string[];
  xref_count: number;
  page_count: number;
  creator: string | null;
  producer: string | null;
}

// A structural verdict describes the file, not the person who sent it, so it
// routes the case — it is never the sole basis for an automatic rejection.
function evaluateDocumentResult(
  result: HTPBEResult,
  claimsInstitutionalOrigin: boolean
): 'accept' | 'review' | 'request_from_issuer' {
  if (result.status === 'modified') {
    // Certain-confidence markers: conclusive finding — hold the file and
    // require a fresh copy straight from the issuer.
    const certainMarkers = [
      'HTPBE_POST_SIGNATURE_EDIT',
      'HTPBE_SIGNATURE_REMOVED',
      'HTPBE_DATES_DISAGREE',
    ];
    const hasCertain = result.modification_markers.some((m) => certainMarkers.includes(m));
    if (hasCertain) return 'request_from_issuer';

    // High-confidence: always route to a human reviewer.
    return 'review';
  }

  if (result.status === 'inconclusive' && claimsInstitutionalOrigin) {
    // Consumer-software origin for a document claiming bank/gov origin:
    // could not confirm integrity (not proof of fraud) — ask the issuer.
    return 'request_from_issuer';
  }

  return 'accept';
}

For workflows that need to flag assembled multi-page documents, HTPBE_PAGES_FROM_MULTIPLE_SOURCES is one of several markers the aggregate verdict weighs together – the API returns the combined result, so you act on the verdict rather than re-deriving the signal yourself.

One signal among several

Page-assembly evidence is one input among many. A document can be altered in ways that leave no trace of assembly, which is why the verdict draws on many checks rather than this one.

The full forensic analysis also examines metadata, timestamps and the file’s revision structure, and the verdict is the combined result. The PDF xref table forensics post covers how the revision history independently surfaces modification – a complementary signal to page-assembly analysis.

Who this matters to

Developers building document intake pipelines for lending, HR, insurance, or legal tech platforms can use this marker to triage documents that warrant manual inspection. It is not a binary reject signal in isolation – it is a routing signal that sends specific document patterns to a review queue rather than auto-accept.

Security researchers and forensic analysts can read the modification_markers array alongside the revision data in the same response to get a fuller picture of how a document was put together than revision counts alone give.

The HTPBE? API returns this and all other forensic markers in a single response. The entry plan covers 30 documents a month (see current pricing) – or use the web tool to run an immediate check: free to try, with 5 free checks on signup, then pay-per-check credit packs.

The March 2026 integrity report shows how often the assembly checks fired in the first month they were available, and the April report how they grew as a share of flagged files.