FreeSign

Verifier · browser-only

Check whether a signed PDF is genuine.

Drop any signed PDF below — FreeSign, DocuSign, Adobe Sign, or anything else. We'll tell you who signed it, whether it has been changed since, and when it was signed. The file never leaves your browser.

Works on PDFs signed by any standard provider, not just FreeSign. Adobe Reader's green/yellow icon is a separate question about local trust settings — we explain that in the result panel.

No signed PDF on hand? Try a sample: sealed-good.pdf (drop it back here — expect 4 green ✓) · sealed-tampered.pdf (one byte flipped in the signed region — expect CMS & OTS to fail; chain & TST stay green)

Audit trail

FreeSign keeps an append-only, hash-chained audit log for every envelope — each event commits to the one before it. This check fetches that chain and re-computes every link in your browser; it does not trust FreeSign's own verdict. Unlike the signature checks above, this one needs the FreeSign service to be online — the audit log lives in FreeSign's database, not inside the PDF.

What a green chain verdict means — and what it doesn't. A valid chain proves the log is internally consistent and untouched by anyone without write access to FreeSign's database. The chain is not signed and not anchored outside that database, so it does not, on its own, prove the timeline against the FreeSign operator. The document's authoritative tamper-evidence does not rely on this chain: it comes from the CMS signature, the RFC 3161 timestamp, and the OpenTimestamps/Bitcoin anchor verified above.

Sign a PDF without uploading it

The verifier on this page is the read-only counterpart of FreeSign's signing flow — both run entirely in your browser, both never see your PDF.

Sign a PDF now →
Technical details for advanced users

What we cryptographically verify in your browser

  • CMS PKCS#7 SignedData (RFC 5652) shape — accepts both DER and BER indefinite-length encoding.
  • SignedAttributes integrity: contentType attr enforced to match encapContentInfo.eContentType; signingCertificateV2 ESSCertIDv2.certHash enforced to match SHA-256 of the leaf cert — leaf substitution attempts FAIL.
  • SignerInfo signature: RSA PKCS#1 v1.5, RSA-PSS, ECDSA P-256/P-384/P-521, or Ed25519/Ed448 — dispatched from the SignerInfo's signatureAlgorithm + digestAlgorithm. SHA-1 digests are rejected.
  • messageDigest cross-check: SignedAttrs.messageDigest must equal digest(ByteRange) computed with the same algorithm.
  • Certificate chain: leaf's TBSCertificate signature is cryptographically verified against the embedded CA's public key (not just DN byte-match). Validity windows are checked against the TST genTime when present (authoritative) rather than the signer-claimed signingTime (unattested).
  • RFC 3161 TimeStampToken: messageImprint matches the digest of the outer signature (algorithm read from the TST), the TST's own SignerInfo signature is verified against the embedded TSA cert, and the TSA cert validity covers genTime.
  • OpenTimestamps Bitcoin anchor (FreeSign-specific): when a Bitcoin attestation marker is present, the block height is extracted and (with user opt-in) the block hash is resolved via blockstream.info. Calendar-only proofs are marked provisional, not green.
  • Multi-signature PDFs: every signature is verified, not just the most recent revision. Earlier-revision tampering surfaces in the status banner.

What we don't do here

Full SPV verification of the Bitcoin block-header path, X.509 chain validation against an AATL or EUTL trust store (we report the chain; AATL trust-anchor decisions are Adobe Reader's job), CRL/OCSP revocation checking, or full PAdES-B-LT / B-LTA long-term-validation embedding. If you want pure-offline verification with policy decisions, use openssl + pyHanko + ots verify with your own trust stack — our guide walks through it.

How this page differs from Adobe Reader

Adobe Reader and Acrobat Pro evaluate “is the signer's CA on Adobe's approved list or locally trusted?” before showing a green check. AATL is curated by Adobe and joining it is an audited commercial process. FreeSign is not on AATL. Cryptographically, our signatures use the same standards as other PAdES-B-T signatures — the same algorithms, the same standards bodies, the same verifiers (openssl cms -verify, pyHanko sign validate, this page). The Adobe UX is a separate question from cryptographic validity. FAQ entry goes deeper.

Why we add OpenTimestamps

RFC 3161 timestamps rely on the TSA still existing and not having its key revoked. The OpenTimestamps proof commits the same document hash through public aggregation calendars and can upgrade to a public block-header attestation. This is the durable, vendor-independent timestamp layer; the RFC 3161 timestamp is the immediately verifiable layer. They cover for each other.