How to Tell if a PDF Was Flattened: Print-to-PDF as a Fraud Evasion Tactic

There is a common belief among people who alter documents: if you edit a PDF and then “print it back to PDF,” the edits disappear. Open the file in Word or a desktop editor, change a number, select Print → Save as PDF, and the new file looks clean. No revision history. No editing-tool fingerprint in the metadata. A clean, single-revision document.

The belief is half true. Flattening — whether through a virtual print driver or a Save Flattened Copy command — really does destroy a specific set of forensic signals. If you stop your analysis at those signals, a flattened forgery passes. This is the single most important reason to understand what flattening does and does not do.

The other half is the part forgers miss: flattening does not produce a clean document. It produces a different document, one that has traded one set of evidence for another. And on a file that claims to come from a bank, a payroll system, or a government office, the new evidence is often more damning than what it erased. This article explains the mechanism honestly, then shows why a flattened institutional document is a routing signal to escalate — not a pass.

What “flattening” and “print to PDF” actually do

The terms get used loosely, so it is worth being precise. Three related operations all collapse a document’s internal history:

• Print to PDF. The document is sent to a virtual printer (Microsoft Print to PDF, macOS Save as PDF, a CUPS-PDF driver). The print pipeline renders each page as if it were going to paper, then writes a fresh PDF from that rendered output. The original file’s object structure is gone — the new file is built from scratch by the print driver.
• Flatten / Save flattened copy. A PDF editor merges all layers, form fields, annotations, and revision data into the base page content and writes a new file in a single pass. Editable elements become fixed marks on the page.
• Re-distill / re-save. The file is re-processed by a tool that rebuilds the object tree (a distiller, a rasteriser, an office-suite re-export). Same effect: the new file has no memory of how the old one was assembled.

In every case, the document is reborn as a fresh object tree — and in the more aggressive variants, parts of it are reborn as a flat raster image with no underlying text or structure at all.

If you want the byte-level mechanics of why an incremental edit leaves a permanent scar in a PDF’s cross-reference structure — the thing flattening is trying to escape — that is covered in our xref table forensics deep-dive. This article is about the opposite move: the attempt to erase that scar entirely, and what it leaves behind.

What a flatten genuinely destroys

Let us be honest about the limitation, because pretending flattening is harmless would be dishonest and would make the rest of this article untrustworthy.

When a document is collapsed into a fresh object tree, several of the strongest forensic signals are genuinely wiped:

• The incremental-update chain. A PDF that has been edited and saved carries a stack of appended revision layers — each edit leaves a new section appended to the file end. A flatten rewrites the whole file in one pass, so the chain resets to a single revision. The history of how many times the file was touched is gone.
• Multi-session assembly fingerprints. When pages are built across several editing sessions, the internal construction often diverges page to page. Re-rendering every page through one print pipeline harmonises them. That divergence signal is erased.
• Original producer lineage. The metadata fields that named the original creating software get overwritten by the flattening tool’s own identity.

So a forger who flattens a tampered file does succeed at making the edit-trail signals disappear. A forensic system that relies only on revision-layer counting or original-producer matching will return a clean verdict on that file. That is a real limitation, and any honest forensic vendor should say so.

But notice what just happened in that last bullet. The forger did not make the metadata empty. They made it say something new.

What a flatten cannot avoid leaving behind

This is the pivot, and it is the whole point.

A document does not get to be born without a parent. When you flatten a file, something renders it, and that something stamps its identity on the output. You cannot produce a PDF without a producer. So the act of erasing the original lineage necessarily writes a new lineage — the identity of the print driver, the office suite, or the editor that did the flattening. The forensic question simply moves from “what edits happened?” to “what kind of software produced this final file, and does that make sense for a document claiming this origin?”

At the outcome level — without handing anyone a checklist to optimise against — a flattened document tends to reveal itself in three ways:

1. A consumer-grade producer identity. The final file now declares that it was made by a desktop print driver, an office suite’s export, or an online conversion service. HTPBE? surfaces this as origin signals such as HTPBE_PRINTED_OUT_OF_PDF_READER (rebuilt by a consumer print-driver utility, erasing original authoring history) or HTPBE_ONLINE_EDITOR_ORIGIN (carries the identity of an online PDF editing or conversion service). The document announces, in its own internal records, that it passed through consumer tooling.

2. Raster-over-vector hybrid characteristics. The more aggressive flattens collapse page content into a flattened image. A genuine institutional statement is almost always sharp, selectable, vector-and-text output straight from the issuer’s reporting engine. A page that has been rendered down to a picture of itself looks very different — HTPBE? describes this outcome as HTPBE_COLLAPSED_TO_RASTER (content collapsed to image form to discard the editing history). It is the structural shape of a document that was photographed by its own print driver rather than generated by an institution.

3. A producer identity that does not match the claimed issuer. This is the one that matters most. When a print-driver or office-suite producer string sits on a file that claims to be a bank statement, HTPBE? can surface a contradiction between the declared institutional origin and the actual construction — markers in the family of HTPBE_PRINT_PIPELINE_TAMPERING (substituted values in a document presented as print-pipeline output) and HTPBE_PRODUCER_IDENTITY_FORGED (a declared institutional generator that was spoofed by a third-party tool to disguise its origin).

I am deliberately not publishing a survives-versus-erased table here. The point of this article is not to hand a forger a map of which signals to optimise against. The point is the conclusion that map leads to anyway: you cannot flatten your way to institutional. You can only flatten your way to consumer-origin. And on the documents fraud teams actually care about, consumer-origin is the alarm.

Why a flattened institutional document is itself the red flag

Here is the fact that makes flattening a losing move for a forger, and it has nothing to do with byte forensics. It is operational.

Banks do not reprint the statements they issue. Payroll systems do not flatten the payslips they generate. Government offices do not run their official letters through Microsoft Print to PDF before sending them to you.

Institutions generate documents from reporting engines that emit clean, single-pass, structured PDFs directly. When your bank’s system produces a monthly statement, that file goes from the reporting engine to your download with no human in the loop and no virtual print driver in the path. The legitimate version of a bank statement never carries a consumer print-driver producer string, because no consumer print driver was ever involved in making it.

So when a document claims to be a bank statement but its internal records say it was last produced by a desktop print pipeline or an online PDF converter, you are looking at one of two things:

• The applicant did something innocuous to a genuine statement (downloaded it, opened it, re-saved it through a tool) — in which case the file is no longer the pristine issuer output and you can no longer verify its integrity, or
• The document was altered and flattened to hide the edits.

You usually cannot tell which from the bytes alone — and you do not need to. Both cases lead to the same operational decision: this is not verifiable issuer output, so escalate it. That is exactly why the correct verdict for a flattened consumer-origin document is inconclusive, not intact.

inconclusive is a routing signal, not a pass

This is where teams new to structural forensics get the verdict logic backwards, so it is worth being explicit.

HTPBE? returns one of three verdicts:

• intact — no modification detected, and the file looks like genuine institutional output.
• modified — positive forensic evidence of post-creation modification (named markers fired).
• inconclusive — the document was created or reprocessed by consumer software, an online editor, or a scanner, so there is no pristine institutional baseline to check integrity against.

A flattened document almost always lands in inconclusive, with a status_reason of consumer_software_origin or online_editor_origin. New users sometimes read inconclusive as “the system couldn’t decide, so let it through.” That is the dangerous misreading.

On a document that is supposed to come from an institution, inconclusive is one of the most valuable answers the API can give. It means: the file you were handed is not the pristine output an institution would have produced — someone put it through consumer tooling first. If you expected a clean bank statement and the document reports consumer-software or print-driver origin, the integrity question is moot. You are not holding issuer output. Route it to manual review or request the document again directly from the source.

The forger who flattens to hide edits has, in trying to reach intact, guaranteed they cannot. They have converted a file that might have passed as institutional into one that is provably consumer-origin — which, on a statement claiming bank origin, is the escalation trigger.

Want to see this on a real file right now? Take any PDF you are unsure about — a statement, an invoice, a letter — and run it through the free PDF tamper check. If it comes back inconclusive with a consumer-software or print-driver origin on a document that claims to be institutional, you have just caught exactly the pattern this article describes.

How HTPBE? reads the post-flatten signals automatically

The whole forensic burden above — “what produced this final file, and is that consistent with what it claims to be?” — is what HTPBE?’s structural analysis does on every upload, without a human reading byte offsets.

It is a single API call. You send a URL to the file; you get back a verdict and the named markers that drove it. There is no numeric risk score to threshold and tune — you branch your workflow on the verdict and the marker IDs.

Step 1 — Submit the document

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

{ "id": "3f9c8b7a-2e1d-4c5f-9b8e-7a6d5c4b3a21" }

Step 2 — Retrieve the verdict

curl https://api.htpbe.tech/v1/result/3f9c8b7a-2e1d-4c5f-9b8e-7a6d5c4b3a21 \
  -H "Authorization: Bearer YOUR_API_KEY"

A flattened statement that claims to be issuer output typically returns something like this:

{
  "id": "3f9c8b7a-2e1d-4c5f-9b8e-7a6d5c4b3a21",
  "status": "inconclusive",
  "status_reason": "consumer_software_origin",
  "origin": {
    "type": "consumer_software",
    "software": "Microsoft: Print To PDF"
  },
  "producer": "Microsoft: Print To PDF",
  "modification_confidence": "none",
  "modification_markers": []
}

Read it correctly: inconclusive plus a consumer print-driver producer on something that should have been a clean bank file is your cue to escalate. When the flatten was aggressive enough to leave positive evidence of tampering, the same call instead returns status: "modified" with markers like HTPBE_PRINT_PIPELINE_TAMPERING or HTPBE_COLLAPSED_TO_RASTER populated in modification_markers.

Step 3 — Branch your workflow

import requests, os

def route_document(result):
    status = result["status"]

    if status == "modified":
        return "REJECT"  # positive tampering evidence

    if status == "inconclusive":
        reason = result.get("status_reason")
        # A document that claims institutional origin should NEVER
        # be consumer-software or online-editor origin. That mismatch
        # is the escalation trigger — flattening lands here.
        if reason in ("consumer_software_origin", "online_editor_origin"):
            return "ESCALATE — request original from source"
        return "ESCALATE — review"

    return "ACCEPT"  # intact, genuine institutional output

The logic deliberately treats inconclusive on an expected-institutional document as an escalation, not a pass. That single branch is what closes the print-to-PDF evasion route: the forger cannot reach intact, and your pipeline does not silently wave through the consumer-origin file they produced instead.

What this approach cannot do — stated plainly

Structural forensics is not omniscient, and it is important to be clear about the edges:

• It does not read the content. HTPBE? does not check whether the numbers on a statement are real, whether an IBAN is valid, or whether a balance matches a bank’s records. A document built from scratch in a tool that genuinely produces clean output — with a fabricated but structurally consistent layout — is out of scope for structural analysis. That is a content-verification and issuer-data problem, a different category of product.
• inconclusive is genuinely ambiguous about intent. It tells you the file is not pristine issuer output. It does not, on its own, prove malice — an honest applicant who re-saved a real statement through an online tool produces the same signal. That is precisely why the right action is escalate and re-request, not auto-reject.
• A sufficiently clean re-generation cannot always be distinguished from original generation. This is the honest limit of any structure-only method, and it is why we frame the verdict as a routing decision rather than a final judgment.

What structural forensics does do, reliably and in a couple of seconds, is strip away the illusion that flattening produces a clean document. It surfaces the consumer-origin reality that flattening always leaves behind, and it puts that signal in front of a human before a forged statement is approved.

Common questions about flattened and re-saved PDFs

Does printing a PDF remove metadata? Partly, and that is the trap. Printing a PDF to a new PDF discards the original metadata — the creating application, the revision-layer history, the producer lineage of the source file. But it does not leave the metadata blank. The print pipeline writes its own identity in their place. So “does printing a PDF remove metadata” has a misleading answer: it removes the old metadata and substitutes new, consumer-grade metadata that is often more incriminating on a document claiming institutional origin. You do not erase your fingerprints; you swap them for the print driver’s.

How can you tell if a PDF was flattened? You cannot reliably tell by eye — a flattened page can look identical to a native one. The signs are structural: a consumer print-driver or office-suite producer string, page content that has been collapsed into an image rather than sharp selectable text, and an origin classification that contradicts the document’s claimed issuer. These are exactly the signals HTPBE? surfaces automatically. The most decisive sign of all is contextual: a document that should be pristine issuer output but reports consumer-software origin has passed through a tool no institution would use.

Is re-saving a PDF the same as tampering? No — re-saving is not itself tampering, and that distinction matters. Plenty of honest applicants open a genuine statement, re-save it through an online tool to compress it, and forward the result with no ill intent. That is why a re-saved document returns inconclusive, not modified. The verdict is not an accusation; it is a statement that the file is no longer the pristine issuer original and its integrity can no longer be checked. The right response is to escalate and re-request the document from the source, not to assume fraud.

What about re-saved PDF tampering that leaves positive evidence? Some flatten-and-edit workflows are sloppy enough to leave behind direct evidence of value substitution on top of the re-emission. When that happens the verdict is not inconclusive but modified, with markers such as HTPBE_PRINT_PIPELINE_TAMPERING populated — the system caught the tampering through the flatten rather than merely flagging the consumer origin.

Who should integrate this

If you run risk or fraud operations at a lender, a fintech, an insurer, or any business that accepts customer-supplied PDFs as evidence — bank statements, payslips, invoices, official letters — the print-to-PDF evasion route is being used against you whether or not you can see it today. The defence is not to detect every edit (flattening makes some edits genuinely invisible). The defence is to recognise that a document which should be pristine issuer output but reports consumer or print-driver origin has already failed the test it was trying to pass.

That recognition is one API call. Get an API key and start checking documents, or create a free account to run your first checks. Send a URL, read the verdict, and treat inconclusive on an institutional document as the escalation signal it is.