FreeSign

Guide

How to sign a PDF without uploading it

Almost every e-signature tool asks you to upload the document first — the provider needs a copy to stamp it. FreeSign doesn't. This guide shows how to sign any PDF locally, in your browser, with cryptographic evidence designed around ESIGN/UETA and eIDAS Article 26 — without ever transmitting the file. Admissibility in any specific dispute is jurisdiction- and fact-specific; if the stakes warrant it, run the artefact past counsel.

Why “without uploading” matters

The standard e-signature flow has the same hole every time: to attach a signature, you hand the signature provider a copy of the document. For a lot of paperwork that's an acceptable trade. For anything confidential — commercial contracts, term sheets, employment offers, board resolutions, medical or legal forms — it's a small but real leak. A third copy ends up on a vendor's cloud storage. Nobody on either side explicitly agreed to that copy existing. The workflow quietly contradicts the document's own confidentiality.

FreeSign is built to remove the contradiction: only you ever hold the PDF. The signature provider (us) sees a 32-byte hash, the email used for the OTP, and a cryptographic signature over a canonical payload. That's it. There is no route, MCP tool, or log line anywhere in FreeSign that takes or stores PDF bytes — it's a structural guarantee, not a setting.

What you'll end up with

Any third party can verify the signature with openssl, pyHanko, Adobe Reader, the in-browser verifier, and the ots CLI — no call back to FreeSign required.

Step-by-step

1. Keep the PDF on your device

Use whatever you'd normally use — a Word/Pages export, your DMS, a tool that flattens a fillable form to a static PDF. Save the file on the device you're signing from. FreeSign works on any PDF Adobe Reader can open. Nothing needs to be uploaded anywhere first.

2. Open FreeSign and drop the PDF

Go to free-sign.com on a browser with WebCrypto (any current Chrome, Firefox, Safari, Edge). Drag the PDF into the dropzone, or click to choose it. The browser computes the SHA-256 locally and shows it onscreen. No bytes have left your machine. The dropzone now shows the first page of the PDF as a preview — that preview is rendered by pdfjs-dist in your browser, not by us. Signing several files? Drop them all at once — each one is hashed and sealed locally in the same ceremony.

3. Enter your email + legal name, accept consent

Email is used only to receive a 6-digit OTP code and to bind the signer's identity into the per-user certificate's subjectAltName. We store the email as an envelope-scoped HMAC, not as plain text. Full legal name goes into the certificate's Subject CN — this is what Adobe Reader shows under “Signed by.”

4. Enter the OTP code

Check your inbox. Enter the 6-digit code in the modal. The browser generates a ceremony keypair (non-extractable WebCrypto), signs a canonical-JSON payload binding the document hash + your consent + the OTP challenge id, and posts it to the Worker. The Worker issues your per-user X.509 leaf cert from the FreeSign CA (HSM-backed, FIPS 140-2 Level 3), submits the signed-region hash to the OpenTimestamps calendar pool, fetches an RFC 3161 timestamp from DigiCert, and assembles the CMS seal. The seal is sent back to your browser; the browser appends it as an incremental update to the PDF.

5. Download the signed PDF

Click Download FreeSign verified PDF. That one file is the complete evidence package: the evidence JSON is embedded inside it — in the signature's CMS, where the certificate chain and timestamp also live — and re-checkable any time with the verifier or openssl cms. You can optionally also click Download timestamp proof for a standalone copy of the .ots file. The signed PDF alone is enough for any standard PAdES verifier.

Sending the signed PDF onward

FreeSign doesn’t run a vendor mailbox — because we never hold your PDF, we can’t (and shouldn’t) relay it. You choose the channel that matches your threat model: e-mail, Signal, your own portal with embed signing, Drive, a USB stick. The recipient receives a normal PDF with an embedded signature; nothing about the file requires them to know FreeSign exists.

If the other party needs to countersign

They drop the signed PDF into free-sign.com and repeat the ceremony. Their signature appends a second incremental revision on top of yours. Both signatures stay verifiable in the same file — Adobe Reader's Signature Panel will list both, openssl/pyHanko can extract both. No coordination through us required.

Handing the file to a verifier

The verifier needs only the signed PDF — the evidence JSON is embedded inside it, in each signature's CMS. With that one file plus public tools, they can independently check that:

  1. The PDF's own SHA-256 is its final_pdf_sha256 (shasum -a 256 signed.pdf).
  2. The consent payload is what was signed (canonical-JSON hash equals evidence.payload_hash).
  3. The signer's identity is bound to the signature (cert's Subject CN + subjectAltName are your name + email).
  4. The signature has an independent timestamp proof (verify the .ots proof with ots verify; after upgrade it resolves to public block headers).
  5. The consent was signed by the browser key bound to this envelope (the embedded evidence carries signature_base64url over the canonical payload plus the matching public_key_jwk; re-verify with WebCrypto). The final-payload signature over the assembled bytes (final_signature_base64url) cannot live inside those bytes — it is available from the signing receipt, GET /api/receipts/{envelope_id}, and verifies against the same public key.

The FAQ → verification section has the exact shell commands for each step, and the openssl + pyHanko + OpenTimestamps guide walks the whole chain end-to-end.

What the legal team needs to know

FreeSign is designed to provide the evidence usually needed for the ESIGN Act (15 U.S.C. §7001) and UETA in the US, and Article 26-style evidence under eIDAS in the EU: signer attribution, consent, association with the record, retention, ceremony-control evidence, and tamper detection via CMS hash + OpenTimestamps. The signature is not a QES (Qualified Electronic Signature) under eIDAS Article 25(2) — that requires a QTSP-issued cert on a QSCD, which is on the roadmap but not in the free product. FAQ → signature classification goes deeper.

FAQ

Does it really never upload the PDF?

Correct. The browser hashes the PDF locally and only the 32-byte SHA-256, the OTP email (as an HMAC), and a signature over a canonical payload reach the server. The CMS seal is built server-side from the hash, sent back, and stitched into the PDF in your browser. The document bytes never travel. See /llms.txt and the verifier for the technical detail.

What kinds of PDF can I sign this way?

Any static PDF Adobe Reader can open — contracts, NDAs (there's a dedicated NDA walkthrough), offers, invoices, consent forms, board resolutions. Flatten fillable forms to a static PDF first if you want the field values baked in before signing.

Can a counterparty's platform (e.g. DocuSign) ingest a FreeSign-signed PDF?

Yes — it's a normal PAdES-B-T PDF with a CMS signature. They can countersign through their own workflow if they want; both signatures stay verifiable independently.

Adobe Reader shows a yellow ⚠️ next to the signature. Is something wrong?

No. The FAQ Adobe explainer reproduces the exact warning and explains that it is about Adobe's commercial trust list (AATL), not document integrity. Repeat recipients can do a one-time local trust setup to turn it green.

Sign a PDF right now

No account, no card, no upload. Under a minute end-to-end.

Open free-sign.com →