Was this bank statement edited after the bank wrote it?

Editing a statement leaves marks in the file. A PDF editor saves by adding to the end, so the original page is still in the bytes. Drop the PDF and see what the file records about its own history.

What it looks for

No account, no upload retained. Parsed in memory, discarded with the response.

Drop a statement here, or

PDF or photo · Max 10 MB · processed in memory, never stored

No statement handy? Try the samples:

Three fictional documents: a utility statement, because a real bank's cannot be published, and the mechanics are identical: the edited copy has a second revision that lowered the printed total, and the signed copy was altered after signing.

What this finds

Most edits to a statement: a lowered balance, a deleted line, a changed name. Are made by opening the bank's PDF in an editor and saving it. That leaves traces the editor cannot help writing:

A PDF grows by appending, so an edited statement still contains the page the bank wrote.
ONE EDITED FILE, TOP TO BOTTOM REVISION 1 · THE BANK WROTE THIS %PDF-1.7 · /Producer the page, its fonts, the real total xref · trailer · %%EOF REVISION 2 · APPENDED LATER a replacement page, a retyped value xref /Prev · trailer · %%EOF Which tool wrote the file. A consumer editor here is a fact worth explaining. Where a signature stops covering. Anything below this line was added after signing. A number typed in a different tool. It brings a second subset of the typeface with it. Counting revisions is exact. What a second revision means is not: see below.

This is the shape of an edited file, not a finding of fraud. Stamping, signing and form-filling append a revision the same way an edit does, and the report names the benign cause next to every signal.

  • An appended revision. PDF editors save by adding to the end of the file, not rewriting it. The original page, the real total, is still in the bytes, and the report says what changed between revisions.
  • A value in the wrong font. Retyping one number embeds a second subset of the typeface, a signature of text added with a different tool. On single-revision files this is reported as information rather than escalated, because ordinary generators can produce it too, that recalibration is published, with the false-positive study that forced it.
  • The wrong toolchain. Banking systems print through server-side libraries. A statement whose metadata names a consumer PDF editor is a fact worth explaining, and the report separates tools that create documents from tools that consume one.
  • A signature that no longer covers the page. If the statement was digitally signed and then altered, the signature's declared byte range stops before the change. The "signed, then modified" sample shows exactly that.
  • Metadata that argues with itself: creation and modification stamps, ID pairs and toolchain claims that do not agree with the file's own revision count.

Every finding is reported with its evidence and its benign explanation. An appended revision is also what a payroll system's stamping step produces; a second font subset is also what merging two honest documents produces. This page reports signals, never a fake/genuine verdict. The reader who knows where the document came from is the only one who can weigh them.

What it cannot see

A checker that implies more coverage than it has is worse than none. Three limits, stated plainly.

  • A statement re-generated from scratch. Print-to-PDF, save-as in the wrong tool, a template rebuild or a statement generator all produce a cleanly written file with no editing traces, because nothing was edited. Byte-level inspection cannot catch a document whose problem is that it was never the bank's. Catching that class needs a reference for the issuer's genuine output, private issuer baselines exist for exactly this, or verification at the source.
  • A photographed or flattened statement. An image of a statement has no revision chain, no fonts and no signature to read. The image engine reports what image metadata and pixels expose, which is less, and the report says which engine ran.
  • Whether the numbers were ever true. A structurally pristine file proves the bytes were written once, by one tool. It does not prove the account exists or the balance was real. If you hold the copy the bank sent, comparison answers a stronger question than inspection can; if you need ground truth, only the bank has it.

Reading the result

Signals mean questions, not a caught forger. Ask for the original download from the bank, or for access to the account feed. A quiet result is consistent with an untouched file, and is also what a competent re-generation looks like. Quiet is evidence, not proof. The field guide walks every signal with real examples, and what 190 published US bank PDFs actually look like inside is the measurement behind the toolchain reasoning above.