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. Need to sign one instead? Use FreeSign's free e-signature — same privacy property.

Works on PDFs signed by any standard provider, not just FreeSign — a browser-only PAdES validator that checks the signature, chain and timestamps of PAdES-B-B / B-T documents (it reads B-LT files too; long-term-validation policy checks are out of scope — see the technical details below). Adobe Reader's green/yellow icon is a separate question about local trust settings — we explain that in the result panel.

Sign a PDF Sign PDF Verify a signed PDF Verify PDF

No signed PDF on hand? Try a sample: sealed-good.pdf (drop it back here — expect 4 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 anchors (FreeSign-specific): both the document anchor (…65834.1.1, over SHA-256 of the ByteRange) and the signed-attributes anchor (…65834.1.5, over SHA-256 of the DER SignedAttributes) are evaluated by the same code and reported under this one check — the second is surfaced to callers as checks.ots.signedAttrs. Either one broken next to an intact classical signature is a caveat, not a failure: neither attribute is covered by that signature, so anyone can append or corrupt one on any signed PDF. Calendar-only proofs may trigger allowlisted GETs to public OpenTimestamps calendars (commitment path from the embedded proof, not the raw file hash) to load a Bitcoin-upgraded tree; when a block-header marker is present, the height is extracted and (with user opt-in) the block hash is resolved via blockstream.info. Calendar-only proofs without a marker stay 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.

The post-quantum co-signature (sixth check)

When present, the PDF carries an ML-DSA (FIPS 204) signature over the same DER SignedAttributes the classical signature covers: a signed commitment to SHA-256 of the ML-DSA public key at OID 1.3.6.1.4.1.65834.1.3, and the public key plus signature as an unsigned attribute at OID 1.3.6.1.4.1.65834.1.4. This page verifies both halves locally with @noble/post-quantum (no browser ships ML-DSA in WebCrypto yet). A swapped key, a bad signature, or a commitment whose signature was stripped out of the mutable /Contents gap all fail. Three cases are caveats rather than failures, because they say nothing about the document: a signature attribute with no signed commitment (unauthenticated — anyone can append one to any PDF, so it is ignored), a post-quantum half that verifies while the classical signature above does not (the classical signature is what binds the key to the signer), and the library failing to load. Absent on both sides is informational. The commitment is only worth what dates it, so this check also cites the verdict on the signed-attributes OpenTimestamps anchor (…65834.1.5) above: only once that anchor reaches a Bitcoin block header is the timing of the key commitment backed by hash-based, quantum-resistant evidence rather than by the classical signature and the RFC 3161 timestamp alone. Full write-up: post-quantum co-signature.

Why we add OpenTimestamps

RFC 3161 timestamps rely on the TSA still existing and not having its key revoked. The OpenTimestamps proofs commit the same document hash — and, in the second anchor, the signed attributes' 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.