How to verify a signed PDF without Adobe Acrobat

What Acrobat's signature panel checks

Many signed PDFs carry a certificate-based digital signature: a cryptographic signature made with a digital certificate and embedded in the file. Adobe Acrobat's signature panel is the best-known way to check one. Youtrust's guide to validating signatures in Acrobat (as published on October 11, 2026) sums up the two questions it asks:

• Integrity: "Is the data consistent with what was signed? Was the PDF altered after the signature?"
• Trust: whether the certificate "was expired or revoked when it was used or if it appears in the certificate store".

Acrobat shows the result in a banner: a green tick ("Signed and all signatures are valid"), an orange mark ("At least one signature has problems") or a red cross ("At least one signature is invalid"). According to the same guide, a green tick needs a certificate from a provider on the Adobe Approved Trust List (AATL) or the EU Trusted Lists (EUTL), and "an orange mark does not always mean there is a problem." Documenso's documentation describes the same split: a green checkmark when the certificate authority is on the AATL, and a warning that the certificate is not from a trusted source when it is self-signed.

On most e-signature services, that embedded signature is the platform's seal rather than each signer's. Documenso's documentation says it directly: "The signature is applied at the platform level, not by individual signers." So a green tick tells you the file hasn't changed since the platform sealed it and that Adobe recognizes the platform's certificate.

Free ways to check a signed PDF without buying Acrobat

As published on their own pages on October 11, 2026:

Option	What it checks	Keep in mind
Adobe Acrobat Reader	Certificate-based PDF signatures, in the same signature banner	Free: Adobe advertises it as "Free. Always". It is still an Adobe app to install
The European Commission's DSS demonstration validator	Certificate-based signatures in the PAdES, XAdES, CAdES and JAdES formats	Your file is uploaded: "Your files are going to be transmitted to the infrastructure of the European Commission." The page asks you to "use documents that do not contain sensitive material" and to limit use "to testing purposes only"
The signing vendor's own tools	What the vendor recorded or sealed	Depends on the vendor, as the examples below show
Attest's verifier, for Attest documents	Each signer's passkey signature and entries, the original document, the pages you see and Attest's anchored record on Horizen	Free and open source. It runs in your browser, and the file is never uploaded

When checking depends on the vendor

Certificates have expiry dates, which is why long-term validation exists: Adobe describes its LTV timestamps as extending "the validity of the signed agreement beyond the time scope of the signer's actual certificate." Some vendors document that checking their documents later goes back through them. As published on their own pages on October 11, 2026:

• Dropbox Sign: "If you ever need to prove there was no tampering… Dropbox Sign can provide you with the two unique document records."
• Signaturit (in a help article of April 12, 2021): downloaded documents' "validity won't last forever, as certificates must be updated", and Signaturit recommends downloading them again from its platform for lawsuits.
• Clicksign: for documents signed more than 12 months earlier, Clicksign's certificate must first be renewed through Clicksign's own validator.

How an Attest signed PDF is checked

Attest takes a different route: its proof is built from open standards, so checking it doesn't depend on a certificate authority, a trust list or Acrobat's signature panel. It uses WebAuthn (W3C) for signatures, SHA-256 (NIST FIPS 180-4) for fingerprints, and Merkle trees for anchoring.

• Each signer signs with their own passkey. A passkey is a cryptographic key only the signer controls, which they use with Face ID, Touch ID, Windows Hello or the device PIN. It signs a statement that names the document's SHA-256 fingerprint and the fingerprint of everything that signer entered.
• The evidence travels inside the PDF. It is appended after the visible pages as an incremental update, so the pages' bytes stay exactly as they were. Attached are attest-evidence.json (the full evidence), original-document.pdf (the document exactly as signed) and attest-verifier.html (the standalone verifier).
• The fingerprints are anchored on a public blockchain. The signed state and the signed copy's pages are anchored on Horizen, a public blockchain anyone can read. Only fingerprints go on chain, never the document.
• The verifier is open. It is open source under the MIT license, on GitHub at DataHubz/attest-verifier, where each release lists the SHA-256 of its file. The current version is published at attest.datahubz.com/attest-verifier.html.

Any PDF reader opens an Attest signed copy and lists its attachments. The check itself runs in the verifier.

Step by step: verify an Attest PDF in your browser

The full check, with no Attest service involved (verify a signed document, step by step shows what each result means):

1. Save the verifier. Open the PDF's attachments and save attest-verifier.html, or download it from the verify page.
2. Open attest-verifier.html in any browser.
3. Drop the signed PDF on it. It checks the original document inside the signed copy against what every signer signed, each signer's passkey signature and entries, Attest's anchored record of the agreement on Horizen, and that nothing was added to the PDF after it was sealed. It also re-makes every page you see from what was signed (the original document, each signer's signed statement and entries, and the completion details Attest anchored: the verification code, the completion time, where each entry sits and the steps up to completion) and compares the result with the copy byte for byte, so pages drawn with anything else fail. It pins its trust root (the chain, Attest's registry and the keys it checks against are built into the verifier, never read from the file being checked), accepts only anchors from Attest's registered wallets, and reads only a public blockchain node, which can be any node of that chain.
4. If one byte of the document, of any signer's entries or of the signed pages changed, verification fails.

Apart from its on-chain checks (Attest's anchored records of the agreement and of its pages, and that the verifier attached to the copy is a build Attest published), the verifier works offline. To check by hand instead, the evidence file lists every step, and each cryptographic check can be run with standard tools: any SHA-256 tool, any WebAuthn library and any Ethereum JSON-RPC node. Re-making the pages uses the open-source renderer published with the verifier.

Online, at attest.datahubz.com/verify:

1. Drop the signed PDF on the page. It is fingerprinted in your browser and never uploaded, and a sealed signed copy is found by its fingerprint, so a match means it is the exact file that was recorded.
2. To see the agreement's record as well, type the verification code printed at the foot of every page (ATT-XXXX-XXXX) and select Verify. The code checks the record, not the file: only step 1 shows that this PDF is the one recorded. If the agreement's certificate is public, it opens, re-checks every passkey signature and reads the anchor from the blockchain in your browser, and shows each signer's name and signing time.

Why this still works if Attest is gone

The verifier inside the copy depends on no Attest service, only on a public blockchain node. Attest put this to a real test: an agreement signed on attest.datahubz.com and anchored on Horizen was verified with Attest blocked, by the verifier inside its signed copy, and changing its pages made it fail. The film, "We blocked Attest. The agreement still verified.", is on the signing page. For more on keeping proof after a vendor closes, see what happens if your e-signature company shuts down.