How to verify a signed document, step by step

Three ways to check

Section 1 is the full check of a signed PDF, on your device. Section 2 confirms in seconds that a file is the exact one recorded. Section 3 starts from a printed page or a stamp's code. A proof link (azk_...) opens its one fact the same way: see how to share proof that you signed. Ways to check an Attest document compares them.

Every check is free and needs no account. The video above shows each one on the real app.

1. Check the signed PDF with the open verifier

This is the full check. It runs on your device, with no Attest service involved.

1. Get a verifier. Click Download the standalone verifier on attest.datahubz.com/verify, or open attest.datahubz.com/attest-verifier.html. Every signed copy also carries one: in a PDF reader with an attachments panel, such as Adobe Acrobat Reader, save attest-verifier.html from the PDF's attachments. The verifier is open source under the MIT license, on GitHub at DataHubz/attest-verifier, where every release is published with its SHA-256, and dropping a downloaded copy on attest.datahubz.com/verify confirms it is the published release.
2. Open it in any browser. It shows its version and a Check for a newer version button, which contacts nothing until you click it.
3. Drop the signed PDF on "Drop a signed PDF or an evidence file here", or click there to choose it. Nothing is uploaded.
4. Read the verdict at the top. A complete pass reads "Verified: the pages you see, re-made here from what was signed, the document, every signer's passkey signature and entries, and Attest's record of the agreement, anchored on the public blockchain." Under it are the title, the signers' names, the completion time, the verification code and when it was anchored.
5. Read the checks below it, from the top:
   • "The verifier attached to this file is Attest's release", with its version: its fingerprint is anchored on Horizen by Attest's platform wallet, which the verifier pins, so the copy inside the PDF is one Attest published. This check means most when the verifier you are running came from Attest's site or GitHub, not from the file itself.
   • "The signed state names this agreement, its document and every signer's statement".
   • "The original document inside is exactly the one signed".
   • For each signer, by name: their entries are the ones they signed; their signed statement names this agreement, its document, their entries and where they appear, and names them by a salted commitment, never their email address; and their passkey signature is valid.
   • The signed state, and "Attest's record of this agreement, its signatures and what its signed copy shows", each "anchored on Horizen by an Attest wallet".
   • "The pages you see are exactly the document as signed": the verifier re-made them, byte for byte, from the original document, every signer's entries and the completion details Attest anchored.
   • "The same pages, anchored when the copy was sealed".

The verifier pins its trust root: the chain, Attest's registries, the registry authority, the site where passkeys sign and the circuit keys are built into it, never read from the file being checked, and it accepts only anchors from Attest's registered wallets. Apart from the on-chain checks, it works offline. It reads Horizen's public node unless you type another node of Horizen under "Node for the on-chain checks"; it checks that the node belongs to that chain.

When a check fails

The verdict then reads "This record does not verify: see the failed checks below.", and each failed check is marked with a cross.

The failed check	What it means	What you can do
"The pages you see aren't what was signed"	The visible pages differ from the pages re-made from what was signed	Don't rely on them. Save the pages as signed (re-made here) gives you the pages as they were signed
"Something was added to this file after Attest sealed it"	Something was added after sealing, which a PDF reader would show on top of the signed pages	The signed pages themselves are intact: Save the signed pages exactly as signed gives you them
"The original document inside is not the one signed"	The attached original was replaced	Ask a party for their copy: every party downloads the same sealed file
"A file attached to this PDF isn't one Attest published"	The verifier attached to the file isn't a release Attest published	Don't open that attached copy. Check the file with a verifier from Attest's site or from GitHub
"Attest's record of this agreement ...: not anchored by Attest"	Attest's anchor of the agreement isn't on Horizen	If the agreement was completed in the last few minutes, check again shortly; otherwise the file's evidence was changed: ask a party for their copy

Two results mean "wait", not "fail":

• "Not verified yet: part of this record isn't anchored yet." The signed copy was sealed moments ago, and the anchor of its pages is on its way. Check again in a few minutes.
• A check ending "the on-chain check couldn't run here". The verifier couldn't reach a node. Check your connection, or type another Horizen node, and drop the file again. Until then the verdict reads "Not fully verified".

2. Check the file online, in seconds

1. Open attest.datahubz.com/verify, or verify.datahubz.com, which shows only the verifier.
2. Drop the PDF on "Or drop the original file here". Your browser computes its fingerprint, and the file is never uploaded.
3. A sealed signed copy is found by its fingerprint. The result reads Verified: content with this fingerprint "existed no later than" the time it was anchored "and has not been altered since", with the recorded claim "Sealed signed copy:" and the title ("Signed pages (without certificate pages):" for a Signed pages only file).
4. A file changed in any way matches nothing, and the result reads "No matching receipt".

This confirms you hold the exact file that was recorded and anchored; the open verifier in section 1 checks everything inside it. Dropping the original document of a completed agreement whose certificate is public shows "No matching receipt", since Attest records the signed copy rather than the original, and lists the agreement below it under "Signed agreements with this document". If the result reads "Recorded, anchoring shortly", the copy was sealed moments ago: check again a little later.

3. Check from a printed page or a code

A printed page can't prove its own words, but its stamp leads to the record.

1. Find the verification code (ATT-XXXX-XXXX) on any Signed with Attest stamp, or in the seal line at the foot of any page of the document.
2. Scan the stamp's QR code with your phone's camera, type the code at attest.datahubz.com/verify and click Verify, or open verify.datahubz.com/ followed by the code.
3. The agreement's certificate opens, noting "You reached this record from a signature stamp." As it loads, it shows the document's fingerprint as every signer signed it, then your browser re-checks each signer's signature ("verified in your browser"), recomputes the signed state ("Signed state recomputed in your browser") and reads the anchor ("Anchor read from Horizen mainnet by your browser"), ending with "Signed and sealed".
4. Read What this check covers: every passkey signature, the signed state and the anchor. It also says what a record can't show: whether a particular file or page is the signed document. To check a paper, compare it with the signed copy.
5. For more detail, click Check the signatures in your browser. For each signer, it confirms that the passkey signed exactly this consent statement, that it was signed on Attest and not a lookalike site, that the passkey belongs to Attest, that the signer was present and verified (Face ID, Touch ID, Windows Hello or PIN), and that the signature is valid for the signer's passkey public key.
6. Under Fingerprints, note the fingerprints of the original document and of the signed copy. A file whose fingerprint matches one of them is that exact file, unchanged.

The certificate shows the title, the file name, the verification code, the fingerprints of the document, the signed copy and the signed state, each signer's name and signing time, the blockchain anchor and each signature's evidence. It never shows the document, and it shows signers' email addresses only to the parties. If the certificate is private, the lookup says the agreement exists and is private: ask one of the parties for a zero-knowledge proof instead.

What a pass tells you

A full pass means each signature was made with a passkey only that signer controls, which confirmed the signer was present and verified, over exactly the document and entries you hold, and that the signed state was anchored on Horizen at the block time shown. How to verify that a signed document is genuine explains what each check proves, and why.

To go further by hand, every cryptographic check can be repeated with standard tools (any SHA-256 tool, any WebAuthn library and any Ethereum JSON-RPC node), and re-making the pages uses the open-source renderer published with the verifier.