Documenso vs DocuSeal vs OpenSign: self-hosted e-signature in 2026

Quick Answer (October 2026): All three sign PDFs properly. They embed a real cryptographic signature, not a flattened picture of a squiggle. The decision is not "which one actually signs" but who holds the signing key and what licence you inherit. Pick Documenso if the key must live in an HSM or at a qualified trust provider, because it is the only one of the three that ships a transport for that. Pick DocuSeal if you want signing to work on first boot with no certificate work at all, and you can live with an attribution clause. Treat OpenSign as the one to check before you commit, because its public repository has been silent for 50 days and its licence points at a file that is not there.

Every figure below was read from the live registries and repositories on 10 October 2026, not from anyone's comparison page.

The thing that is the same, and nobody says it

The search results for these three are full of people asking whether open-source signing is "real" signing. For all three, the answer is yes, and you can verify it from the dependency manifests rather than the marketing.

• Documenso signs through @libpdf/core 0.5.2 (MIT) with pdfjs-dist 5.4.296 for rendering. The library's own registry keywords include digital-signature, pkcs7 and signing.
• DocuSeal signs through the Ruby hexapdf gem, currently 1.11.1.
• OpenSign signs through @signpdf/signpdf with @signpdf/signer-p12 and @signpdf/placeholder-pdf-lib, all pinned at ^3.3.0, over pdf-lib 1.17.1. Its signing path constructs new P12Signer(P12Buffer, { passphrase }) and hands it to new SignPdf().

So all three produce a PKCS-style cryptographic signature embedded in the document, where any later edit breaks the signature. That shared baseline is why the interesting differences are elsewhere.

Licensing: the SPDX field is wrong on two of the three

This is the part that would have cost us the most if we had trusted GitHub's licence badge, and it is wrong in opposite directions.

DocuSeal ships a 185 byte LICENSE_ADDITIONAL_TERMS that reads, in full, that under Section 7(b) of the AGPL "a covered work must retain the original DocuSeal attribution in interactive user interfaces." GitHub reports DocuSeal as plain AGPL-3.0 and says nothing about this. If you are embedding a signing flow into your own product and intended to white-label it, that single sentence is the most consequential thing in this entire comparison, and the licence badge hides it.

OpenSign has the opposite problem. Its NOASSERTION is a scanner artefact of the preamble, not a sign that the licence is unknown. The bulk of the file is ordinary AGPL-3.0. What the preamble does is carve out everything under apps/OpenSignServer/cloud/customRoute, which it says is "licensed under the license defined in" that directory.

We checked whether that directory exists, because the clause is conditional. It does. It holds four entries: customApp.js, decryptpdf.js, docxtopdf.js and a deleteAccount subdirectory of five files. We then checked for the licence it points at. There is no licence file of any name in that directory or its subdirectory. So the carve-out is live, it covers real code including PDF decryption and DOCX conversion, and the terms it defers to are not published in the public repository.

The fair reading is that this is probably a by-product of how that repository is maintained, which we come to below, rather than anything deliberate. The practical reading is unchanged: the only repository you can read does not tell you the terms for part of its own code.

One more supply-chain detail worth knowing: DocuSeal's PDF engine hexapdf is itself published under AGPL-3.0 and a nonstandard licence, so a company trying to escape AGPL obligations has a second AGPL layer underneath the first.

Who holds the key

This is the real decision, and the three are genuinely far apart.

Documenso exposes NEXT_PRIVATE_SIGNING_TRANSPORT with three values: local, gcloud-hsm and csc. That third one matters more than its small name suggests. The Cloud Signature Consortium standard is how a remote provider holds the signing key on your behalf, and it is the only route among these three toward a signature where the key never sits on your server at all. Documenso also takes NEXT_PRIVATE_SIGNING_TIMESTAMP_AUTHORITY as a comma-separated list, documented in its own .env.example as enabling "LTV and archival timestamps". Long-term validation is what keeps a signature verifiable after the signing certificate has expired.

DocuSeal takes the opposite approach, and its certificate generator in lib/generate_certificate.rb is worth reading. On first use it builds an entire three-tier public key infrastructure for you: a self-signed root CA, a sub-CA signed by that root, and a leaf signing certificate signed by the sub-CA. RSA 2048 (SIZE = 2**11), a hundred year validity on all three, country hardcoded to Austria, and the leaf correctly marked CA:FALSE with keyUsage of Digital Signature.

That is a real certificate chain and a real signature. It is also self-signed, which means a PDF reader will report the signature as valid but of unknown provenance rather than showing a green tick, unless someone installs that root. This is not a defect. It is the correct trade for a tool that wants to work the minute the container starts, and DocuSeal clearly expects you to graduate: it reads a CERTS environment variable for your own certificate, a TRUSTED_CERTS variable for a trust list, carries a timestamp_server_url key in its encrypted configuration, and defines a constant named docuseal_aatl, a reference to the Adobe Approved Trust List.

OpenSign takes exactly one certificate, as PFX_BASE64 plus PASS_PHRASE. No HSM option, no remote provider, and we found no timestamp or RFC 3161 handling anywhere across the three files that make up its signing path.

A warning for anyone comparing these by reading filenames. DocuSeal has lib/generate_certificate.rb and OpenSign has pdf/GenerateCertificate.js, and they do completely different things. DocuSeal's builds X.509 certificates. OpenSign's builds a PDF audit summary page using pdf-lib and fontkit, and contains 46 references to fonts and two to certificates. A comparison written from directory listings would report that both auto-generate certificates. Only one does.

Maintenance, and why the dates on GitHub lie

Every repository page shows a "last updated" and a last push. On this trio, both are actively misleading, in both directions.

updated_at read within hours of each other for all three repositories, which would suggest three equally busy projects. It is useless. The last push is worse than useless:

Documenso's repository had been pushed to minutes before we ran this. All ten of its most recent activity events are force_push to a branch called chore/translations, every one of them by github-actions[bot], roughly every two hours around the clock. Read naively, that makes Documenso look like the most active project here. The bot tells you nothing.

What tells you something is the default branch and the release feed, and on those Documenso looks genuinely healthy: human commits on main from named contributors, with v2.20.0 tagged on 8 October 2026. There is one detail we liked a lot. Its core PDF library @libpdf/core published 0.5.2 at 13:05 on 7 October, and Documenso's commit upgrading it landed at 13:39 the same day. Thirty-four minutes. That is a project watching the library that does its cryptography.

DocuSeal is the cleanest maintenance signal of the three and the quietest about it. Every one of its ten most recent events is a human pushing straight to master, roughly weekly, back through August. It has exactly one branch. No bots in the recent history at all. Its last release, 3.3.1, landed on 5 October 2026.

OpenSign needs its own explanation, and the obvious reading is too harsh. Its last activity of any kind was 21 August 2026, which happens to be the exact timestamp of its v2.41.3 release tag. Neither its default branch (staging, unusually) nor main has anything newer. But look at what its commits say: they are merges of pull requests from an organisation called nxglabs, with branch names of the form sync-to-public_repo-NNNN. The public repository is a mirror, not the place the work happens.

So "50 days of silence" is not the same claim as "abandoned". Development may well be continuing privately. What is true, and what matters if you are choosing a tool to run yourself, is narrower and still awkward: the window you are allowed to see through has been shut for 50 days, you cannot observe the development that may be happening, and the missing licence file in the carved-out directory is exactly the kind of thing a sync that does not copy everything would produce.

The numbers, for completeness

A note on that issue count, because GitHub will mislead you here too. The open_issues_count on the API includes pull requests. The raw numbers are 214, 124 and 154, which overstate the real issue backlog by 86, 29 and 36 respectively. The table above splits them.

For a Next.js team there is one more entry worth knowing: DocuSeal publishes official embed packages, and @docuseal/react 1.0.75 is MIT, not AGPL. The server you host is AGPL with the attribution clause; the React component you drop into your own frontend is not. Documenso and OpenSign have embedding, but no comparably packaged React component on the registry.

The decision rule

• You need a qualified or HSM-backed signature, because a regulator, an auditor or a counterparty demands the key never sit on your application server. Documenso. It is the only one of the three with a transport for it, and the only one advertising archival timestamps for long-term validation.
• You want signing working today and you will not be rebranding the UI. DocuSeal. It is the only one that signs with no certificate work, it has the steadiest human maintenance record here, its React embed is MIT, and the attribution clause is a real but survivable constraint.
• You are embedding signing into a commercial product and cannot ship AGPL. None of these three, as-is. Your honest options are a commercial licence from the vendor, a commercial signing API, or building the signing step yourself, which is more reachable than it sounds given that both @libpdf/core and the @signpdf family are MIT and available independently of the applications that wrap them.
• You liked the look of OpenSign. Check the repository before you commit, not after. If the public mirror has moved since this was written, the picture changes; if it has not, you are adopting a tool whose development you cannot see and part of whose licence is not published.

On that third branch, the surrounding application is usually the larger half of the work: accounts, storage, an audit trail, a database and somewhere to deploy it. Totalum is one way to get that part, generating an exportable TypeScript and Next.js app with its own database, auth, file storage and PDF generation, and it states you can "view, edit, and download the complete source code at any time". To be exact about it, PDF generation is not PDF signing, and signing is not included; you would still add that yourself with the MIT libraries above. The same caveat applies to any app platform you pick for this.

What we did not test

We read registries, repositories, licence files, dependency manifests and signing source. We did not install any of the three, did not sign a document, and did not open a signed output in Adobe Acrobat to see what each one's signature panel reports. The self-signed conclusion for DocuSeal follows from reading its certificate generator, which is strong evidence about what it builds and not a substitute for watching a reader validate it.

We also did not check whether OpenSign supports timestamps somewhere outside the three files in its signing path. We looked in PDF.js, GenerateCertificate.js and Placeholder.js, found nothing, and verified the same search pattern does fire on Documenso's configuration, so the search itself works. That is a bounded absence, not a proof.