Can this tell me whether a bank statement is fake?

No tool can prove that from the file alone, and this one does not claim to. What it can establish is what the file's own structure records: whether revisions were appended after creation, whether values sit in a different font than their neighbours, whether a consumer editor touched a document that claims to come from a banking system, and whether a digital signature still covers what the page shows. Each finding ships with its evidence and its innocent explanation, and the decision stays with you.

What does an edited bank statement look like inside the PDF?

The commonest edit is an appended revision: PDF editors save changes by adding a new section to the end of the file, leaving the original bytes in place. The file then carries two versions of itself, and the earlier one is recoverable. Other traces include a second font subset for a typeface where one value was retyped, an editor's name in the producer metadata, and a signature whose byte range stops before the appended change.

What kind of tampering does a byte-level check miss?

A statement re-generated from scratch — printed to a fresh PDF, rebuilt in a template, or produced by a generator — carries none of the editing traces this page reads, because nothing was edited: the file is cleanly written, just not by a bank. Catching that class needs a reference for what the issuer's genuine output looks like, or verification at the source. This page says so rather than implying coverage it does not have.

Is the statement I upload stored anywhere?

No. The file is sent over HTTPS, parsed in memory and never written to disk. The report is returned in the response and the document is discarded with it.

Was this bank statement edited after the bank wrote it?

Drop a statement here, or browse

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

The edits people actually make to statements — a lowered balance, a deleted transaction line, a changed name — are almost never made by rebuilding the document. They are made by opening the bank's PDF in an editor and saving. That act leaves traces the editor cannot help writing:

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 and often say so — or say nothing at all. A statement whose metadata names a consumer PDF editor carries a fact worth explaining, and the report distinguishes tools that create documents from tools that consume an existing 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

A statement that comes back with signals is a statement with questions attached, not a caught forger — ask the applicant for the original download, or for access to the account feed. A statement that comes back quiet is consistent with being untouched, 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.