A few years ago, a small law firm in the Midwest discovered that their "secure" online signing platform had been storing every document their clients uploaded — contracts, settlements, employment agreements, medical releases — on an unsecured cloud storage bucket. Anyone with the right URL could download them. The firm found out when a journalist called to ask why their client's divorce settlement was publicly accessible.
That story isn't unique. It's not even rare. Cloud-based signing services process millions of documents a year. Most are secure. Some aren't. And you, as the person uploading the document, have no way to tell which is which.
This is the core problem with cloud-based PDF signing: you have to trust the service with your document. Not just during signing, but before, during, and after. The document sits on their server. It's processed by their software. It's stored in their database. It's backed up to their cloud provider. And you're relying on their security practices — which you can't audit — to keep it safe.
What Cloud Signing Actually Does
Let's trace what happens when you sign a PDF with a typical cloud-based signing service.
You visit the website. You click "Upload Document." Your browser sends the PDF to the service's server. The server stores the document — usually in a database or object storage bucket. The server renders the document and sends a preview back to your browser. You draw or upload your signature. Your browser sends the signature data to the server. The server combines the signature with the document, generates the signed PDF, stores it, and sends you a download link.
At minimum, that document existed on the service's server in three forms: the original upload, the intermediate processed version, and the final signed version. It was probably logged. It might have been backed up. It might have been indexed for search. It might have been retained for compliance, or for "quality improvement," or because nobody configured the retention policy to actually delete things.
Now, most reputable services do secure this process. They use encryption in transit (TLS) and at rest (encrypted storage). They have access controls. They have audit logs. They're probably fine.
But "probably fine" is not the same as "provably safe." And when the document is a sensitive contract, a medical release, or a legal settlement, "probably fine" isn't good enough.
Client-Side Signing: A Different Model
Client-side signing flips the architecture. Instead of sending your document to a server, the server sends the signing application to your browser. The application — a JavaScript program — runs entirely on your device. It reads your PDF from disk, processes it in memory, applies your signature, and writes the signed PDF back to disk. The document never touches a server.
This is how our Digital Signer works. When you load the page, your browser downloads the signing application — the JavaScript, the PDF processing library, the UI components. After that, everything happens locally. The PDF you select is read by the browser's File API and processed in memory. Your signature is drawn, typed, or loaded on your device. The signed output is generated in your browser and downloaded directly.
No upload. No server storage. No retention policy. No cloud bucket to misconfigure.
The Security Difference, Concretely
Let's compare the two approaches across specific security dimensions:
### Data Exposure
**Cloud signing:** Your document is transmitted over the network to a third-party server. It exists on infrastructure you don't control. If the service is compromised, your document is exposed. If the service misconfigures storage, your document is exposed. If a rogue employee accesses the database, your document is exposed.
**Client-side signing:** Your document exists only on your device and in your browser's memory. It's never transmitted. There's no server to compromise, no storage to misconfigure, no database for a rogue employee to access. The attack surface is your device — which you already control.
### Network Interception
**Cloud signing:** Even with TLS, your document traverses the network. A compromised certificate authority, a man-in-the-middle attack, or a compromised network device could intercept the document in transit. These scenarios are unlikely but not impossible.
**Client-side signing:** No network transmission of the document. Nothing to intercept.
### Retention and Data Residency
**Cloud signing:** The service may retain your document for hours, days, or indefinitely. You typically can't verify deletion. The document may be stored in data centers in jurisdictions you don't know about, subject to laws you haven't considered.
**Client-side signing:** No retention. The document exists on your device before and after signing. You control when and how it's deleted. No data residency concerns because no data leaves your device.
### Audit Trail
**Cloud signing:** The service maintains the audit trail — timestamp, signer identity, authentication data. This is convenient but means your audit trail is stored on someone else's server, accessible to them and potentially to law enforcement or litigants via subpoena.
**Client-side signing:** The audit trail is generated on your device and embedded in the signed document or provided as a separate record. You control it. You store it. You decide who sees it.
When Cloud Signing Makes Sense
I'm not going to pretend client-side signing is always the right choice. It isn't. Cloud-based signing services offer features that browser-based local signing can't match:
**Multi-party workflows.** When five people need to sign the same document in sequence, a cloud service manages the routing, notifications, and signing order. Client-side signing is a single-signer experience.
**Identity verification.** Some cloud services offer ID verification, knowledge-based authentication, or biometric signer verification. These require server-side processing.
**Third-party integrations.** Cloud signing services integrate with CRM systems, document management platforms, and business workflows. Client-side signing is standalone.
**Long-term archival.** Some services offer tamper-evident long-term storage with timestamping. If you need this, a cloud service provides it.
For these use cases, cloud signing is the right tool. Use it. Just be aware of what you're trading for the convenience.
When Local Signing Is the Right Call
For most individual signing tasks, client-side signing is not just safer — it's simpler. If you're signing a contract or agreement yourself, filling and signing a form, adding a signature to a document before sending it to someone else, signing a sensitive document you don't want on a third-party server, working offline or on a slow connection, or concerned about data privacy and retention — then local browser-based signing is the better choice.
It's faster (no upload/download round-trip), more private (no server exposure), and more secure (no third-party trust required). You can try it right now with our SignSeal tool. Open a document, sign it, and download — the whole process happens in your browser. Or read more about how to sign PDFs without Adobe or uploads.
The Trust Question
Security is fundamentally about trust. Who do you trust, and with what?
Cloud signing asks you to trust the service provider — their security practices, their retention policies, their employees, their cloud infrastructure, their legal jurisdiction. That's a lot of trust to give a company you've never met, for a document you care about.
Client-side signing asks you to trust your own device and the signing application running in your browser. That's it. The trust boundary is your machine.
For sensitive documents, that smaller trust boundary is the whole point. Your contract, your signature, your computer. No middleman.
The Midwest law firm I mentioned at the start? They switched to client-side signing after the breach. Not because cloud signing is inherently unsafe — it isn't — but because they decided the risk of exposing client documents to a third party wasn't worth the convenience. For them, the calculation was clear.
For you, it might be different. But at least now you know what the calculation is.
