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.

The belief is half true. Flattening – whether through a virtual print driver or a Save Flattened Copy command – rebuilds a document from scratch, and some of what a file records about its own past does not survive that. A check that relied on that record alone would have little to say about a flattened forgery. 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, a real part of its forensic history is genuinely wiped:

• Part of the file’s history. Some of what the file recorded about how it was handled after creation does not survive being rebuilt from scratch.
• The original lineage. What the file says about the software that first created it is replaced by the flattening tool’s own identity.

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 leaves its mark on the output. So the act of erasing the original lineage writes a new one – 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-software origin. The final file now carries the traces of whatever rebuilt it – a desktop print driver, an office suite’s export, or an online conversion service.

2. Page content reduced to an image. Some flattening routes turn a page into a picture of itself – the shape of a document re-rendered by consumer tooling rather than issued by an institution.

3. An origin that contradicts the one the document presents. This is the one that matters most. When a file presented as institutional output was in fact built by other tooling, HTPBE? can surface that contradiction. The named checks are listed in outcome terms on the how it works page.

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: flattening does not get a document back to institutional. It trades one origin for another, and on the documents fraud teams actually care about, a 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 a desktop print driver before sending them to you.

When a document presented as a bank statement reports consumer-software or print-driver origin, it is not the issuer’s file as issued, and its integrity cannot be confirmed against one.

So when a document submitted as a bank statement comes back as the output of 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 why a flattened consumer-origin document does not come back intact on the strength of the flatten: depending on what the file still shows, it comes back inconclusive or modified.

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 structural evidence of modification.
• 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 that shows no direct evidence of editing comes back inconclusive, with a status_reason such as 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 is trying to reach intact, and the flatten itself stands in the way. A file that was meant to pass as institutional now reads as 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 statement that reports consumer-software origin returns something like this:

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

Read it correctly: inconclusive plus a consumer print-driver origin on something that should have been a clean bank file is your cue to escalate. When the file also carries positive evidence of tampering, the same call instead returns status: "modified", with the markers that drove it listed 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: no structural evidence of modification

The logic deliberately treats inconclusive on an expected-institutional document as an escalation, not a pass. That single branch is what keeps a flattened file from being waved through: the flatten does not buy the forger intact.

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 fabricated from the start, rather than edited after it was created, is outside what modification detection answers. 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.
• No structure-only method catches every case. That is the honest limit of the approach, 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 evidence that flattening typically 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 much of the source file’s history, but it does not leave the file blank – the print pipeline leaves its own traces in place of the old ones. So “does printing a PDF remove metadata” has a misleading answer: it removes the old history and substitutes a new, consumer-grade one 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 rather than visual, and HTPBE? surfaces them automatically as an origin classification and named markers. 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 the verdict is never an accusation: it describes the file, not the person who sent it. A document that passed through consumer tooling is no longer the pristine issuer original, and its integrity can no longer be checked against one. 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 files still carry direct evidence of tampering. When that happens the verdict is modified, with the markers that drove it 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. 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.

Print-to-PDF output is the leading producer in both the February and March 2026 integrity reports.