FreeSign FAQ

1. Adobe Reader shows "At least one signature has problems"

2. How to verify a FreeSign signature

TL;DR — you have two files: the signed PDF and an evidence record you downloaded after signing. Send them both to whoever needs to check the signature. They open the PDF in Adobe Reader to see who signed it and that it hasn't been changed. If they want extra assurance, they can run free public tools on those two files to confirm everything — without ever calling FreeSign. Five separate checks are possible, all listed below.

The five things a verifier can prove

1. 1. The PDF hasn't been changed

   The file in your hand is byte-for-byte the same PDF the signer downloaded. If even one byte was altered, this check fails. The fingerprint is the bedrock identity of the document.

2. 2. The signer really agreed to these terms

   The signer agreed to a specific consent text, on a specific date, after confirming a code we e-mailed them. In a dispute, this is the cryptographic equivalent of "I agree." If anyone changed the consent text after the fact, this check fails.

3. 3. The signer's name and e-mail are baked into the signature

   The certificate embedded in the PDF carries the signer's typed legal name and the e-mail address they confirmed during signing. That's what Adobe Reader's "Signed by" line shows, and that's what any legal review reads.

4. 4. There's an independent timestamp proving when it was signed

   Nobody can backdate a FreeSign signature. The signing time is committed to a public, independent timestamp ledger — one that doesn't depend on FreeSign being around to confirm it later.

   For the first 1–2 hours after signing the proof is "pending" while the public batch settles. That's normal — re-run the verify command later to pick up the confirmed proof.

5. 5. The same browser that agreed also sealed the final file

   The browser signs twice: once when the user agrees, and once over the final assembled PDF. Both signatures use the same browser-held key, so nobody could have swapped in a different PDF after the signer clicked "I agree."

Shell commands for each of the five checks — shasum, openssl, ots verify — live in the Technical details section at the bottom of this page.

What does the verifier not need?

• A FreeSign account — there isn't one to create.
• An API key — no FreeSign endpoint is called for the core checks. The signer's public key is archived into the evidence JSON (embedded in the PDF) as public_key_jwk; the receipt at /api/receipts/{envelope_id} stores the same JWK as a cross-check and carries the final-payload signature.
• Trust in FreeSign — every check above relies on public infrastructure (the OpenTimestamps calendar pool and block-header attestation path, the user's leaf cert chain, the FreeSign CA cert which is itself published at /.well-known/free-sign-signing-ca.pem).
• The FreeSign service to keep running — the signed PDF alone is sufficient and stable forever: the evidence JSON, the signature, the cert chain and the timestamp proof are all embedded inside it.

3. Other common questions

What is the OpenTimestamps proof, and why does it eventually mention Bitcoin?

Short answer: it's a public, independent timestamp that anyone can verify without trusting FreeSign — one that keeps working even if we shut down. Bitcoin happens to be the public ledger it settles on, but that's plumbing, not a crypto-currency feature.

OpenTimestamps is the timestamping layer FreeSign uses for vendor-independent proof. It batches many commitments through public calendars, then upgrades those commitments to a Bitcoin block-header attestation once the batch confirms. We lead with OpenTimestamps because that is the artifact you download and verify; Bitcoin is the settlement layer underneath, not a cryptocurrency feature of FreeSign. We still include an RFC 3161 timestamp from DigiCert, but we do not want private timestamping to be the only long-term proof.

What if the user's email changes? Can someone forge a signature?

Short answer: no. The e-mail used at signing time is frozen into that specific signature. Changing your e-mail address tomorrow does not retroactively invalidate or alter past signatures, and does not let anyone else sign as you.

The email is bound at OTP time into the per-user leaf cert (as subjectAltName) and into the canonical payload (as an HMAC). The cert is issued for a fixed 10-year window (set by LEAF_CERT_VALIDITY_SECONDS; the signing key itself is one-shot and destroyed at the end of the ceremony, the cert just outlives it so Adobe's wall-clock validator stays green even years later), signed by FreeSign's Signing CA. Even if the same person changes their email later, the cert for the original signature is frozen — the signature continues to verify against the email that was OTP'd at signing time, and the embedded RFC 3161 timestamp plus the OpenTimestamps proof record the moment beyond the cert's expiry.

Does FreeSign know what I signed?

Short answer: no. We never see the document. We see a fingerprint of it — the same kind that lets you check the file hasn't been altered — plus the act of signing (your e-mail, your name, a timestamp, the connecting IP), which every e-signature service keeps.

Not the document itself. The Worker only receives a 32-byte SHA-256 of the PDF (and later, a 32-byte digest of a region of the PDF used for the signature placeholder). No bytes of the document itself ever transit our infrastructure. If a court subpoenas FreeSign for “the document Ada Lovelace signed on 2026-05-17,” we cannot produce it — we don't have it.

What we do retain is the standard signing-act evidence: the OTP-verified email (as an envelope-scoped HMAC), the consent payload, an audit hash chain, and a request fingerprint with the connecting IP (and any X-Forwarded-For chain), the user-agent, the Cloudflare colo/ASN/TLS metadata, and the OTP timing. That's the same audit-trail surface DocuSign and Adobe Sign retain on the signing event itself, and it's what the next question's impersonation argument leans on. The architectural property is “no PDF bytes,” not “no IPs.”

Can the verifier confirm I signed the document, not someone else?

Short answer: the same way every e-mail-based e-signature service confirms it — whoever was in control of the e-mail inbox at signing time is the signer of record. That leaves dramatically more evidence than a pen-on-paper signature ever would. Identity verification with passports / national ID is a separate (paid, notary-grade) tier we don't offer yet.

Worth being precise about what FreeSign actually proves. We verify the fact of a signature, not the underlying identity of the human. The signed payload binds together a typed legal name (in the leaf cert's Subject CN), an email controlled at signing time (in subjectAltName.rfc822Name), the OTP that the signer retrieved from that inbox, the IP and user-agent of the browser, and an immutable timestamp. We don't see a passport. We don't check a driver's license. Identity assurance is at the OTP level: whoever controlled the email inbox at that moment is who signed.

That's the same trust model as every "click here to confirm" email signature provider, and it's stronger than what the analog world offers. Impersonating someone else when signing is a crime in every jurisdiction we operate in. The question isn't whether impersonation is possible — it's possible with a pen too — the question is what evidence remains afterwards.

Compare to a wet signature on paper: anyone with a pen and a steady hand can copy your scribble. There is no email trail, no IP, no timestamp, no cryptographic binding to a specific document hash, no independent timestamp proof showing when the act happened. A handwriting expert can offer a probabilistic opinion months later in a courtroom — that's the entire forensic apparatus. A FreeSign signature leaves dramatically more evidence than ink on paper: the email that was OTP-verified (which the impersonator would need to have compromised), the IP and ASN of the browser, the geographic data Cloudflare captured, the precise moment the consent was clicked, and an OpenTimestamps proof for the signed hash. An impersonator using FreeSign leaves a forensic trail; an impersonator with a pen leaves less.

For higher-assurance identity (passport / national-ID verification before signing), QTSP-grade upgrade paths exist but aren't in the free product.

Can I sign with Face ID or a passkey instead of an email code?

Short answer: yes — after your first signature on an email address, FreeSign offers to save a passkey. Your next signature on that same email can then replace the emailed one-time code with a single biometric tap (Face ID, Touch ID, Windows Hello, or a hardware security key).

The first signature on any email always uses the emailed code — that is what vouches for the inbox. Once it completes, your browser asks whether to enrol a passkey for next time. A passkey is a hardware-backed credential created by your own device; its private half never leaves the device and is unlocked only by your biometric or device PIN. On a later signature FreeSign detects the passkey and prompts for that tap instead of mailing a code. The passkey produces a WebAuthn assertion bound to the exact thing being signed, and that assertion is embedded inside the signed PDF as extra evidence — such records advertise the evidence v2 schema. Passkeys are an additional identity-and-intent layer; the cryptographic signature itself is unchanged, and the emailed code always remains available as a fallback if a device is lost or the prompt is dismissed.

Why is there a "quick human check" before my code is emailed?

Short answer: it stops bots from using FreeSign to flood someone else's inbox with verification emails. It is a one-click challenge, not a CAPTCHA puzzle, and it usually passes without any interaction.

Before FreeSign emails a one-time code it runs a Cloudflare Turnstile challenge — a privacy-respecting human check that does not track you and, in most cases, resolves silently. Without it, anyone could script the “send code” step to mail-bomb an arbitrary address. A short per-email cooldown (30 seconds by default) sits on top, so even a verified human cannot trigger codes faster than that. Both are abuse controls on the delivery of codes — they have nothing to do with, and never see, your document.

What does FreeSign load from other companies' servers?

Short answer: almost nothing. The code that signs your PDF, and every library it depends on, is served from FreeSign's own domain — not from a third-party CDN — and the browser is told to enforce that.

The whole signing ceremony — hashing, stamping, the cryptographic signature — runs in your browser from JavaScript served by FreeSign itself. The browser libraries it uses (the PDF toolkit, the QR-code generator) are vendored: pinned, byte-checked copies hosted on FreeSign's domain, never pulled live from a content-delivery network. A strict Content-Security-Policy sent with every page tells the browser to refuse any script, worker, or network connection outside a tiny named allowlist — so “no third-party CDN” is a rule the browser enforces, not a promise you have to take on trust. FreeSign also sets the standard hardening headers (HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy) on every response. The few allowed outside origins — the Cloudflare bot-check, a privacy-friendly page-view counter, and the blockchain explorer the verifier uses to resolve timestamps — are listed explicitly and never carry document data.

Does FreeSign check the signature before handing me the file?

Short answer: yes. Before the download link and receipt appear, your browser re-opens the freshly sealed PDF and re-verifies the signature it just produced. If that check fails the ceremony stops — you never receive a broken file.

The last step of every ceremony is a self-check: the same verification engine that powers the public /verify page runs inside your browser against the just-sealed PDF, confirming the CMS signature and the certificate chain back to FreeSign's CA. Only when both pass does the receipt render and the download unlock. It is a defence-in-depth gate — a FreeSign download is always a PDF that already verified once, on your own machine, the moment it was made.

What kind of electronic signature is FreeSign?

Short answer: in the US, an e-signature is an e-signature — there's only one kind, and FreeSign is it. In the EU there's a three-step ladder (simple / advanced / qualified); FreeSign is on the middle rung — "advanced" — which covers the vast majority of contracts. The top rung ("qualified") requires a notary-grade provider and is needed only for a narrow set of special cases (some real-estate deals, certain court filings).

Different jurisdictions classify electronic signatures differently. Here's where FreeSign sits in both.

United States (ESIGN & UETA). US law defines a single category of electronic signature — there are no "tiers." The ESIGN Act (15 U.S.C. §7001) and UETA focus on evidence such as intent to sign, consent to do business electronically, association with the record, and retention/reproducibility. FreeSign is designed to produce that evidence: typed consent, OTP-verified email, document hash bound into the signed payload, a downloadable PDF with the evidence JSON embedded inside it, and an independent timestamp proof. Whether a signature is enforceable in a specific dispute is always fact-specific.

European Union (eIDAS). EU law defines a three-tier ladder under Regulation (EU) No 910/2014:

1. Simple Electronic Signature (SES) — Art. 3(10). Any electronic mark indicating intent (a typed name, a checkbox, an image of a signature). Legally valid (Art. 25) but weakest evidentially.
2. Advanced Electronic Signature (AES) — Art. 26. Adds four hard requirements: uniquely linked to the signatory, capable of identifying them, made under sole control, and any subsequent change to the document is detectable. FreeSign is designed around this evidence model.
3. Qualified Electronic Signature (QES) — Art. 3(12). An AES plus a cert issued by a Qualified Trust Service Provider (QTSP) plus a Qualified Signature Creation Device (QSCD). Carries Art. 25(2) presumption of equivalence to a handwritten signature across all EU member states.

FreeSign's evidence bundle is built for that AES analysis: the browser ceremony has a unique session key, the email-OTP + leaf certificate identify the signatory at the ceremony level, and the CMS hash + OpenTimestamps proof detect tampering and provide time evidence. All three tiers carry possible legal effect under Art. 25(1), but FreeSign does not claim the automatic QES presumption.

SES vs AdES: simple versus advanced electronic signatures

Short answer: a "simple" signature is any electronic mark of intent — a typed name, a ticked box. An "advanced" signature adds four hard, machine-checkable properties on top. Both are legally valid; the difference is how much evidence travels with the signature when someone disputes it. FreeSign produces the advanced kind.

The middle rung of the eIDAS ladder — Advanced Electronic Signature (AES) — is defined by Article 26 as a Simple Electronic Signature (SES) plus four requirements. Here is what each tier does and does not give you.

“AdES” is the same idea seen from the file-format side. “AES” names the legal tier; AdES (Advanced Electronic Signature) names the cryptographic format family that implements it — PAdES for PDF, CAdES for raw CMS, XAdES for XML. FreeSign emits PAdES-B-T: a PAdES baseline signature with an embedded RFC 3161 timestamp, and PAdES-B-LT (long-term validation) when a CA CRL is configured. So “FreeSign is an AES” and “FreeSign produces a PAdES signature” are two ways of saying the same thing.

What does not change between the tiers: an SES is still legally valid and admissible under Art. 25(1) — the EU forbids courts from rejecting a signature merely for being electronic or non-qualified. The advanced tier does not make a signature “more legal”; it makes it self-evidencing, so whoever relies on it carries far less of the proof burden. Add a QTSP-issued certificate on a Qualified Signature Creation Device and an AES becomes a QES — the top rung, covered in the next question. You can verify every AES property of a FreeSign PDF yourself: see the verification guide and the evidence JSON schema reference.

Is FreeSign compliant with the European eIDAS regulation?

Short answer: yes for the kinds of contracts most people sign — employment, NDAs, vendor agreements, leases, consents. No for the small set of EU procedures that specifically require a notary-grade "qualified" signature; those need a different tool. The EU explicitly forbids courts from rejecting an e-signature just because it isn't the qualified flavour.

FreeSign is built for Article 26-style evidence. It is not a Qualified Electronic Signature (QES) and is not issued by a Qualified Trust Service Provider. Here's what that means in practice.

Under Art. 25(1) of eIDAS, an electronic signature cannot be denied legal effect or admissibility in court solely because it's electronic or because it doesn't meet the QES bar. So AES-level signatures — including FreeSign — are fully usable for the overwhelming majority of business and consumer contracts in the EU: employment, NDAs, services agreements, vendor contracts, leases, consents, internal approvals.

Where QES becomes mandatory is a narrow set of cases that vary by member state: cross-border filings with public authorities, certain types of notarial deeds, some real-estate transactions, electronic invoicing in regulated sectors, court filings in specific procedures. For those, you currently need a QTSP-issued cert on a QSCD (e.g. a national-ID smartcard, an HSM-backed remote QSCD, or a mobile-eID such as Smart-ID). FreeSign's roadmap includes a QTSP/QSCD upgrade path; until then, anything requiring the Art. 25(2) presumption needs a different tool.

The Art. 25(2) bonus that QES gets — "equivalent legal effect to a handwritten signature" automatically across the EU — isn't a magic enforceability switch. Non-QES signatures can still be enforceable; they just do not carry that automatic presumption, so in a contested case the party relying on the signature needs evidence. FreeSign's evidence JSON — embedded inside the signed PDF — is designed to provide that evidence: ceremony uniqueness, identity binding, browser-held intent evidence, timestamps, and tamper detection are all inspectable from the single signed file.