Can you spot a fake PIX receipt from the file alone?

The only reliable way to confirm a PIX payment is your own bank: the money either landed in the account or it did not, and no analysis of the receipt can prove payment. What a receipt PDF can still answer is a different question: whether the file was edited after it was created. Drop one and see what its structure records.

What the file can show

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

Drop a receipt here, or browse

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

No receipt handy? Try the samples:

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

Start with the only proof there is

A PIX payment is confirmed in your own bank app or statement, and nowhere else. The money either landed or it did not. For a sale, look for the credit before releasing goods, no receipt, however convincing, substitutes for that.

Two questions, two different authorities. Only your bank can answer the first one; the file can only answer the second.
DID THE MONEY MOVE? Your own bank app or statement. The credit either landed in the account or it did not. Nothing else settles this. WAS THE FILE WRITTEN AGAIN AFTER IT WAS MADE? The file's own structure. Revision chain, producer string, the two date stores, the payload's own check characters. THE ANSWERS DO NOT SUBSTITUTE FOR EACH OTHER A receipt whose bytes were written once, by one tool, proves the bytes were written once by one tool. It does not prove a transfer happened.

This page exists because people search for how to spot a fake comprovante PIX, and most advice stops at "look carefully": check the font, check the alignment, squint at the logo. A well-made fake survives all of that. What squinting cannot read, and file structure can, is the document's own history: whether the bytes were written once by a bank's generator, or written and then written again by something else.

What structure can tell you: when the receipt is a PDF

An edited receipt carries both totals. The appended revision replaces the object that draws the amount; the object it replaced is still sitting above it in the same file.
ONE FILE, TWO REVISIONS revision 1: written once by the bank's generator 12 0 obj · page content · “R$ 1.200,00” revision 2: appended afterwards 12 0 obj · page content · “R$ 12.000,00” WHAT A VIEWER SHOWS R$ 12.000,00 the last xref table wins Both objects are still in the bytes. The report names which object the later revision replaced, and what it held. A receipt forwarded through a stamping or archiving tool also gains a revision: the benign shape of the same structure.
  • An extra revision appended after creation. A bank's app writes the receipt once. PDF editors save changes by adding to the end of the file, leaving the original bytes in place, so an edited receipt carries two versions of itself, and the report says what changed between them.
  • The producer. Bank receipt generators are server-side or in-app libraries, and they name themselves, or say nothing at all. A receipt 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.
  • Dates that disagree. A creation stamp from one moment and a modification stamp from another, or metadata claims that do not agree with the file's own revision count.
  • The PIX payload's own arithmetic. When the receipt carries the copy-and-paste ("copia e cola") payload, that string ends in check characters computed from the rest of it, a CRC. The br-identifier-checksum family redoes the computation: an amount or key retyped inside the payload contradicts arithmetic the issuing system already performed, with nothing to compare against.
The amount is inside the payload as well as printed on the page, and the payload's last four characters are computed from it.
THE COPY-AND-PASTE PAYLOAD, TAIL END …5303986 5406120.00 5802BR6009SAOPAULO 6304A1B2 tag 54: the transaction amount, carried inside the string itself tag 63: four check characters, computed with a CRC over every byte before them RETYPE ONE AND THE OTHER STOPS AGREEING Change the amount in the payload without recomputing the tail and the four characters no longer match the string they were derived from. Arithmetic the issuing system already did, with nothing to compare against.

Field ids are the EMV/BR Code tags a PIX payload uses. The br-identifier-checksum family redoes the computation. A failing check is evidence; a passing one is not. Any generator that implements the rule correctly produces characters that pass.

Each finding ships with its evidence and its benign explanation, a receipt forwarded through a stamping or archiving tool also gains a revision, honestly. Signals, never a verdict.

What structure cannot tell you

  • Anything about a screenshot. Most PIX receipts travel as screenshots, and an image of a receipt has no PDF structure, no revision chain, no fonts, no producer. The image engine reads compression history and image metadata, which are weaker signals and trivially stripped; the report says which engine ran. A quiet screenshot says very little.
  • Whether money moved. A structurally pristine PDF proves the bytes were written once, by one tool. It does not prove the transfer happened, and this page will never claim it does. That answer lives in your bank, full stop.

Where this check earns its place

Not at the counter. There, your bank app is faster and final. File inspection is a second opinion for the cases where the file itself is the question: an after-the-fact dispute over whether a receipt was doctored, an expense report under internal review, an audit trail where a PDF receipt is the artefact on record. In those cases, what the file's structure recorded at save time is evidence nobody can squint their way to. The fake boleto guide covers the neighbouring problem, where printed check digits do even more of the work.

The same check, from your own systems

Everything this page does is one POST to the API: send the PDF or image, get the same report back as JSON, every signal with its evidence and benign causes, thresholds yours to set. 50 documents a month are free, no card required.