How the SHA-256 Signing Certificate Works

What's on the certificate

When both parties have signed a document, Signbee appends a final page to the PDF. This is the signing certificate. It contains six pieces of information:

Every field is recorded at the exact moment of signing. Nothing is editable after the fact. The certificate is embedded directly into the PDF — it travels with the document forever.

SHA-256 in plain English

SHA-256 is a cryptographic hash function. It takes any input — a PDF, a text file, an image — and produces a fixed 64-character string called a hash. Think of it as a digital fingerprint.

Two critical properties make it useful for document integrity:

• Deterministic — The same input always produces the same hash. If you hash the same PDF twice, you get the same 64 characters both times.
• Avalanche effect — Change a single character in the document and the hash changes completely. Not just one character of the hash — the entire thing is different. There's no way to make a “small” change to a document and keep the same hash.

Input: "This NDA is between Alice and Bob"
SHA-256: a7f3b9c2e4d1...8f2a (64 chars)

Input: "This NDA is between Alice and Bob"  (identical)
SHA-256: a7f3b9c2e4d1...8f2a (identical)

Input: "This NDA is between Alice and Bob"
SHA-256: a7f3b9c2e4d1...8f2a

Input: "This NDA is between Alice and Rob"  (Bob → Rob)
SHA-256: f1e8d7c6b5a4...3e9d (completely different)

This means you can verify a document hasn't been tampered with by re-computing the hash and comparing it to the one on the certificate. If they match, the document is exactly as it was when both parties signed.

The signing flow, step by step

Here's what happens behind the scenes when a document is sent through Signbee:

1. Document created — Markdown is converted to a clean PDF, or your existing PDF is ingested. At this point, no signatures exist yet.
2. Sender signs — The sender verifies their identity (via API key or email OTP), then their signature is recorded along with a timestamp and their IP address.
3. Recipient signs — The recipient clicks the signing link, reviews the document, chooses a signature style, types their name, and signs. Their timestamp and IP are recorded.
4. Hash computed — Signbee takes the complete PDF (including both signatures rendered on the document pages) and computes the SHA-256 hash of the entire binary.
5. Certificate appended — A new final page is added to the PDF containing all of the signing metadata and the hash. The certificate is rendered using pdf-lib — drawn directly onto a new A4 page with Helvetica and Courier fonts.
6. Final PDF delivered — Both parties receive the complete signed PDF with the certificate page via email.

What the code actually does

Under the hood, the certificate generation is surprisingly straightforward. The signing certificate module takes a data object and appends a new page to the existing PDF:

interface SigningCertificateData {
  title: string;           // "Mutual NDA"
  documentId: string;      // "cmm..."
  senderName: string;      // "Alice Chen"
  senderSignedAt: string;  // "2026-03-25T14:32:01Z"
  senderIp: string;        // "203.0.113.42"
  recipientName: string;   // "Bob Smith"
  recipientEmail: string;  // "bob@acme.com"
  recipientSignedAt: string;
  recipientIp: string;
  hash: string;            // 64-char SHA-256 hex string
  verifyUrl: string;       // "signb.ee/verify/cmm..."
}

The function loads the existing PDF, adds a new A4 page (595 × 842 points), and draws each field in a structured layout — title and document ID at the top, Party A and Party B sections with their signing details, a document integrity section with the SHA-256 hash in Courier monospace, and a verify URL in amber.

The amber accent bar across the top of the certificate matches Signbee's brand colour — it's immediately recognisable as a Signbee certificate.

Verification

Every certificate includes a verify URL — signb.ee/verify/[document-id]. Anyone with the signed PDF can visit this URL to confirm:

• The document exists in Signbee's database
• Both parties signed
• The SHA-256 hash matches — confirming the document hasn't been modified
• The signing timestamps and verification methods are accurate

This is the “trust but verify” mechanism. Anyone — a lawyer, a client, an auditor — can independently confirm a document's authenticity without needing to contact either party.

Why this matters legally

Electronic signatures are legally recognised under three major frameworks:

• ESIGN Act (US) — Federal law since 2000
• eIDAS Regulation (EU) — Cross-border electronic signatures since 2016
• Electronic Communications Act (UK) — Legal recognition since 2000

All three require an e-signature system to demonstrate intent to sign, association of signature with document, and record retention. The SHA-256 certificate satisfies all three:

Can the certificate be faked?

A common question: what stops someone from creating a fake certificate?

The verification URL is the answer. The certificate includes a signb.ee/verify/[id] link that hits Signbee's database directly. If someone fabricates a certificate with a made-up hash, the verify URL will either return “document not found” or show a hash mismatch. The forgery is immediately detectable.

The SHA-256 hash itself cannot be reverse-engineered or forged. SHA-256 is the same algorithm used by Bitcoin, TLS certificates, and most of the internet's security infrastructure. It has no known vulnerabilities. Modifying a signed document to produce the same hash would require more computational power than currently exists on Earth.

Why we chose SHA-256 over blockchain

We get asked this a lot. Why not put the signature on a blockchain?

The short answer: complexity without benefit. SHA-256 provides the same integrity guarantee — if the hash matches, the document is untampered. A blockchain would add transaction costs, latency, and infrastructure complexity without improving the core guarantee.

The longer answer: blockchain is useful when you need decentralised consensus — when multiple untrusted parties need to agree on the state of something without a central authority. Document signing doesn't have that problem. You have two parties, a single document, and a verification endpoint. SHA-256 + a verify URL is the simplest architecture that provides the guarantee.

Simple systems are more reliable. More auditable. Easier to explain in court.

Try it yourself

Send any document through Signbee and look at the last page of the signed PDF. You'll see the certificate with both parties' details and the SHA-256 hash. Click the verify URL. Compare the hashes. That's all there is to it.

Cryptographic integrity shouldn't require a PhD to understand. The hash either matches or it doesn't. The document is either untampered or it isn't. That's the promise.